neovim - Vim-fork focused on extensibility and usability

Age	Commit message (Collapse)	Author	Files
2026-03-29	feat: extend vim.Pos, vim.Range #36397	Luis Calle	1
	Problem: Using nested `vim.Pos` objects to represent each `vim.Range` object requires 3 tables for each `vim.Range`, which may be undesirable in performance critical code. Using key-value tables performs worse than using array-like tables (lists). Solution: Use array-like indices for the internal fields of both `vim.Pos` and `vim.Range` objects. Use a metatable to allow users to access them like if they were key-value tables. --- Problem: The `vim.Pos` conversion interface for `extmark` indexing does not take into account the difference in how a position on top of a newline is represented in `vim.Pos` and `extmark`. - `vim.Pos`: for a newline at the end of row `n`, `row` takes the value `n + 1` and `col` takes the value `0`. - `extmark`: for a newline at the end of for `n`, `row` takes the value `n` and `col` takes the value `#row_text`. Solution: Handle this in the `extmark` interface. --- Problem: Not all `to_xxx` interfaces have wrapping objects like `to_lsp`. Solution: Return unwrapped values in `to_xxx` interfaces where it makes sense. Accept unwrapped values in "from" interfaces where it makes sense. --- Problem: `start` and `end` positions have different semantics, so they can't be compared. `vim.Range` relies on comparing the `end` and `start` of two ranges to decide which one is greater, which doesn't work as expected because this of the different semantics. For example, for the ranges: local a = { start = { row = 0, col = 22, }, end_ = { row = 0, col = 24, }, } local b = { start = { row = 0, col = 17, }, end_ = { row = 0, col = 22, }, } in this code: local foo, bar = "foo", "bar" -- \|---\|\|-\| -- b a The range `b` is smaller than the range `a`, but the current implementation compares `b._end` (`col = 22`) and `a.start` (`col = 22`) and concludes that, since `b.col` is not smaller than `a.col`, `b` should be greater than `a`. Solution: - Use a `to_inclusive_pos` to normalize end positions inside of `vim.Range` whenever a comparison between a start and an end position is necessary.
2025-11-09	fix(lsp): don't overlay insertion-style inline completions (#36477)	Riley Bruins	1
	* feat(lua): `Range:is_empty()` to check vim.range emptiness * fix(lsp): don't overlay insertion-style inline completions Problem: Some servers commonly respond with an empty inline completion range which acts as a position where text should be inserted. However, the inline completion module assumes that all responses with a range are deletions + insertions that thus require an `overlay` display style. This causes an incorrect preview, because the virtual text should have the `inline` display style (to reflect that this is purely an insertion). Solution: Only use `overlay` for non-empty replacement ranges.
2025-09-15	fix(lsp): avoid automatic request after leaving insert mode (#35767)	zeertzjq	1
	This also fixes the following warning in tests with ASAN or TSAN: -------- Running tests from test/functional/plugin/lsp/inline_completion_spec.lua RUN T4604 vim.lsp.inline_completion enable() requests or abort when entered/left insert mode: 225.00 ms OK RUN T4605 vim.lsp.inline_completion get() applies the current candidate: 212.00 ms OK nvim took 2013 milliseconds to exit after last test This indicates a likely problem with the test even if it passed! RUN T4606 vim.lsp.inline_completion get() accepts on_accept callback: 212.00 ms OK RUN T4607 vim.lsp.inline_completion select() selects the next candidate: 220.00 ms OK -------- 4 tests from test/functional/plugin/lsp/inline_completion_spec.lua (3437.00 ms total) -------- Running tests from test/functional/plugin/lsp/linked_editing_range_spec.lua nvim took 2011 milliseconds to exit after last test This indicates a likely problem with the test even if it passed!
2025-09-08	test(lsp): fix flakiness in inline completion test (#35676)	zeertzjq	1
	The flakiness happens because get() uses vim.schedule(), and a following key may be processed before the scheduled event. Use poke_eventloop() to ensure that the scheduled event is processed.
2025-09-01	feat(lsp): vim.lsp.inline_completion on_accept #35507	Yi Ming	1

2025-08-25	feat(lsp): support `textDocument/inlineCompletion`	Yi Ming	1