Problem:
Use vim.lsp.util.apply_text_edits to re-apply the same textedit causes
an incorrect edit, because apply_text_edits silently modifies the
parameter.
Solution:
- Avoid changing `text_edit._index`.
- Document this fun feature.
Helped-by: Riley Bruins <ribru17@hotmail.com>
Helped-by: Yi Ming <ofseed@foxmail.com>
(cherry picked from commit 790a8be5f3)
Co-authored-by: geril07 <62308020+geril07@users.noreply.github.com>
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem:
Cursor-position `vim.lsp.buf.code_action()` requests include all diagnostics on the current line, so unrelated same-line diagnostics affect the returned actions.
Solution:
Filter same-line diagnostics to the cursor position for cursor-position requests.
(cherry picked from commit ecb8402197)
Problem:
The fromRanges field of the result of callHierarchy/outgoingCalls is
documented as being relative to the caller. Using
vim.lsp.buf.outgoing_calls() opened the qflist with an entry with the
callee's filename, but the caller's line number.
Solution:
Open the qflist with the callers file (the bufnr from the request),
rather than the callees (the uri from the resulting CallHierarchyItem)
(cherry picked from commit 7e006b06c4)
Problem:
LSP spec allows response message to have a null request-id.
This may happen when for example client sends unparseable request.
https://github.com/microsoft/language-server-protocol/issues/196
Solution:
Guard the server response branches against id=vim.NIL (json null),
and handle error responses with null id by logging a warning
and dispatching on error.
Problem:
CI (ubuntu asan, ubuntu tsan, windows) reports `uv_loop_close()
hang?` from the two new null-id response tests. The leaked
handle is the server-side accepted TCP socket created inside
`server:listen` callback. The tests closed only the listener
but not the accepted socket, so libuv could not finish shutting
down the loop and each test session took ~2s extra to exit.
Solution:
Hoist the accepted socket to the outer `exec_lua` scope and
close it at teardown before closing the listener. The close
runs synchronously inside `exec_lua`, so the loop has time to
dispose the handle before the session exits.
* test(lsp): close accepted socket on read-loop exit/error
Match the precedent in the handler test ("handler can return
false as response") and the shared `_create_tcp_server` helper
in `test/functional/plugin/lsp/testutil.lua`: close the
accepted socket from inside the `create_read_loop` exit/error
callbacks. The teardown close added in the previous commit
remains as belt-and-suspenders, so the socket is disposed
whether the server goes away first or the client does.
Problem:
After on_refresh() sends a textDocument/codeLens request, the buffer may
be deleted before the response arrives. The response callback then tries
to redraw that deleted buffer and raises Invalid buffer id error.
Solution:
Check buffer validity before redrawing.
AI-assisted: Codex
Co-authored-by: Yi Ming <ofseed@foxmail.com>
(cherry picked from commit 97caa88972)
Problem: completionItem/resolve response's `detail` field is silently
dropped. Only `documentation` is shown in the popup.
Solution: Prepend `detail` as a fenced code block before `documentation`
in the info popup, skipping if documentation already contains it.
(cherry picked from commit b351afb1b1)
test: lint naming conventions
Problem:
Naming conventions are not automatically checked.
Solution:
Add a check to the doc generator. Eventually we should extract this
somehow, but that will require refactoring the doc generator...
Note: this also checks non-public functions, basically anything that
passes through `gen_eval_files.lua` and `gen_vimdoc.lua`. And that's
a good thing.
Problem
Some variables use the wrong type (ClientToServer instead of ServerToClient)
and some use vaguer types that could be more strict.
Solution
Use the correct types.
(cherry picked from commit 530cfa1323)
continues d0af4cd909.
This commit renames positional parameters. This is only "cosmetic", but
is intended to make it extra clear which name is preferred, since people
often copy existing code despite the guidelines in `:help dev-naming`.
(cherry picked from commit 71ac4db335)
Problem: vim.lsp.util.show_document insert mode is unable
to set the cursor after the target character position if the target character
is at end of line.
Solution: Move cursor after the target character (in append position)
in this case.
(cherry picked from commit 891bb0e6ce)
Problem: _get_and_set_name edits the name for the whole group,
thus only one client per group gets the didOpen message.
Solution: move the logic to _changetracking and loop over every
client per group.
(cherry picked from commit 37eb1b9979)
Problem: hover/signature callback lacked consistency checks, so slow LSP servers
could open a float after the cursor had already moved away.
Solution: guard the callback with buf validity, buf version, and cursor
position checks before opening the float. Also fix table capacity calculation.
(cherry picked from commit af9a72d8c1)
feat(api): rename buffer to buf
Problem:
`:help dev-name-common` states that "buf" should be used instead of
"buffer" but there are cases where buffer is mentioned in the lua API.
Solution:
- Rename occurrences of "buffer" to "buf" for consistency with the
documentation.
- Support (but deprecate) "buffer" for backwards compatibility.
Co-authored-by: Jordan <46637683+JordanllHarper@users.noreply.github.com>
Problem:
Since 2f6d1d3c88, `apply_text_edits`
unconditionally sets `buflisted=true`, causing spurious BufDelete events
if plugins restore the original 'buflisted' state on unlisted buffers:
65ef6cec1c/src/nvim/option.c (L2159-L2169)
Solution:
- Don't set 'buflisted' in `apply_text_edits`. Set it more narrowly, in
`apply_workspace_edit` where the semantics requires affected buffers
to be visible to the user.
- Also skip setting 'buflisted' if it would not be changed, to avoid
redundant `OptionSet` events.
(cherry picked from commit 6473d007e7)
fix(health): misleading warnings re filetypes registered w/ vim.filetype.add() #38867
Problem:
`:checkhealth vim.lsp` validates configured filetypes against
`getcompletion('', 'filetype')`. This only reflects runtime support
files.
This causes false warnings in `:checkhealth vim.lsp` for configured
filetypes that are known to the Lua filetype registry, including
values added with `vim.filetype.add()` and built-in registry-only
filetypes.
Solution:
Build the healthcheck's known-filetype set from both
`getcompletion('', 'filetype')` and `vim.filetype.inspect()`.
(cherry picked from commit 20a3254ad4)
Co-authored-by: Barrett Ruth <62671086+barrettruth@users.noreply.github.com>
Problem:
The current LSP diagnostic implementation can't differ between a pull
diagnostic with no identifier and a set of diagnostics provided via push
diagnostics.
"Anonymous pull providers" are expected by the protocol https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#diagnosticOptions
, depending on how the capability was registered:
- Dynamic registrations have an identifier.
- Static registrations will not.
Solution:
Restore the `is_pull` argument removed in
https://github.com/neovim/neovim/pull/37938, keeping the identifier of
pull diagnostic collections.
(cherry picked from commit 665ebce569)
Problem: `buf` is optional even though its needed to perform conversions
and the ordering of `(buf, row, col)` is not consistent.
Solution: make `buf` mandatory on `vim.range` and `vim.pos` and enforce
the `buf, row, col` ordering
(cherry picked from commit 01be30f638)
Problem:
The snippet preview is not being highlighted by treesitter for
completion items from servers which don't support
`completionItem/resolve` (like gopls). This was broken by #38428.
Solution:
Call `update_popup_window` after updating the completion item with the
snippet preview.
I've added assertions to the `selecting an item triggers
completionItem/resolve + (snippet) preview` test case which covers the
snippet preview being shown since no tests failed when I removed the
`nvim__complete_set` call which actually populates the preview on this
codepath.
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.
Problem:
When following this example from our docs the Copilot LSP won't attach.
Solution:
Add `init_options` as done by [`nvim-lspconfig`](1a6d692067/lsp/copilot.lua (L112-L121)).
Problem: clangd prepends a space/bullet indicator to label. With
labelDetailsSupport enabled, the signature moves to labelDetails,
making label shorter. This flips the length comparison in
get_completion_word, causing it to use item.label directly and
insert the indicator into the buffer.
Solution: only prefer filterText over label when label starts with non-keyword
character in get_completion_word fallback branch.
Problem: Generating snippet preview in get_doc() populated the
documentation field before resolve, so the resolve request was
never sent.
Solution: Move snippet preview logic into on_completechanged and
the resolve callback so it no longer blocks the resolve request.
Problem: Default swatch unicode character got lost.
Solution: Put it back where it belongs.
---------
Co-authored-by: vnadgaonkar-spec <vnadgaonkar@gmail.com>
Co-authored-by: Christian Clason <ch.clason+github@icloud.com>
The `buffer` option remains functional but is now undocumented.
Providing both will raise an error. Since providing `buf` was disallowed
before, there is no code that will break due to using `buffer` alongside
`buf`.
Problem:
f9b2189b28 started using namespaces
for pull diagnostics that look like this `<id>:<identifier>`.
`vim.lsp.buf.codeaction` passes `true` instead of an identifier
to `vim.lsp.diagnostic.get_namespace`, resulting in a namespace that
looks like `<id>:nil`. The end result is that none of the diagnostics are
passed to `textDocument/codeAction` request. Because of that server
might not send any code actions back. For example, eslint lsp responds
with an empty list of actions if it receives no diagnostics.
Solution:
use `_provider_foreach` to collect diagnostics from all `identifiers`
and use that identifier to get a namespace instead of `true`.
If a user accepts completion and immediately exits insert mode, it
could happen that `Context.cursor` was nil by the time the
`completion/resolve` response arrives, leading to an error.
Problem
The format of LSP log messages is inconsistent; some include underscores, while others are not logged at all.
Solution
Standardize log recording and unify the log message prefixes with the module names.
Problem:
The capability attach path for client/registerCapability can initialize a capability even when the capability was only registered in specific buffers
Solution:
Check supports_method() before attaching capabilities from the dynamic registration handler so unsupported registrations are ignored.
AI-assisted: OpenCode
- Add TODO comments for aggregating diagnostics from all pull namespaces
and for clearing diagnostics when an empty array is received, referencing
the LSP specification.
- Update diagnostics refresh logic to safely access previousResultId,
preventing potential nil errors.
Previously, resultId for diagnostics was keyed only by client_id, which
could cause issues when multiple identifiers are used by the same client.
This change introduces a composite key of client_id and identifier for
client_result_id, ensuring correct tracking of diagnostic results per
identifier. Updates all relevant logic to use the new keying scheme.
Previously, the LSP client assumed all providers had subcapabilities,
which could cause issues when a provider did not. This change adds a
check for the presence of subcapabilities before attempting to access
them, ensuring correct handling of both cases. This improves
compatibility with servers that register providers without additional
capabilities.
Update diagnostic refresh to request diagnostics from all provider
registrations using _provider_foreach. This ensures diagnostics are
fetched from every registered provider during a refresh.
Co-authored-by: ZieMcd <ziemcd@gmail.com>
Introduce _provider_foreach to iterate over all matching provider
capabilities for a given LSP method, handling both static and dynamic
registrations. Update diagnostic logic and tests to use the new
iteration approach, simplifying capability access and improving
consistency across features.
Problem:
`vim.lsp.document_color.color_presentation()` throws, due to incorrect use of the `vim.Range` API.
Solution:
Change `vim.Range.has(a, b)` call to `a:has(b)`.
Problem:
When code lens is enabled, `on_attach` is executed, but it does not trigger a redraw. Another event, eg, moving the cursor, is required to trigger a redraw and execute the decoration provider's `on_win`.
Solution:
Trigger a `redraw` after each request is completed.
