Problem:
`CompletionItem.detail` is only shown in the info popup if the server
supports `completionItem/resolve`.
Solution:
If the server doesn't support `completionItem/resolve`, prepend the
complete item `info` with `CompletionItem.detail` in a fenced codeblock,
same as we do when the server supports `completionItem/resolve`.
To ensure that completion items are displayed in the same way,
regardless of whether the server supports `completionItem/resolve`, i've
extracted out the test logic from the `selecting an item triggers
completionItem/resolve + (snippet) preview` case so that we can run the
same tests against a server which supports `completionItem/resolve` and
one which doesn't. Hopefully this should prevent the two behaviours
diverging again.
Problem:
If `CompletionItem.documentation` is populated but `detail` is not, then
`detail` is not resolved.
Solution:
Ensure that we resolve a `CompletionItem` if either `detail` or
`documentation` are not populated.
I've also removed `detail` from the popup menu since otherwise it will
be populated in both the popup menu and the info popup after the
`CompletionItem` has been resolved. I think the info popup is the best
place for it anyway as when there is a completion item with a long popup
menu entry (when `detail` is a medium/long function signature for
instance), the whole popup menu gets widened and this steals horizontal
space that could be used to display the `documentation`. Now with
`detail` and `documentation` in the info popup, they share the same
horizontal space. This also aligns with how VSCode, nvim-cmp, blink.cmp,
and mini.nvim display `detail`.
Problem:
When a resolved `CompletionItem` with kind `Snippet` populates
`textEdit` instead of `insertText`, the contents are not previewed.
Solution:
Generate the snippet preview from `textEdit.newText` as well.
Problem:
After 767fbd8, typing trigger chars would open completion but the
chars were removed.
Solution:
Use filterText fallback so selected item respects typed trigger chars.
Problem:
PlainText completion items used `textEdit.newText` or `insertText` as
the completion word even when they did not match the typed prefix. This
could break popup completion behavior like 'completeopt+=longest'.
Solution:
Fall back to `filterText` when `newText` or `insertText` does not match
the typed prefix.
Problem:
Error when querying document symbols using python-lsp-server:
lsp/util.lua:1955: attempt to concatenate field 'containerName' (a userdata value)
Solution:
Check for `vim.NIL`.
Problem: With `vim.g.health = { style = 'float' }`, running
`:checkhealth` from a `:help` buffer placed the float in the
top-left corner instead of centered.
make_floating_popup_options() picks the NW/NE/SW/SE anchor
and the available height from cursor-relative metrics
(winline(), wincol(), winheight()). When the caller passes
relative='editor', those metrics are meaningless, so the
function could flip to an 'E' anchor and clamp the float
off-screen.
Solution: When relative='editor', treat the whole editor area as
available space (lines_above=0, lines_below=&lines,
wincol=0). This makes the NW anchor the natural choice and
keeps the float position stable regardless of where the
cursor is in the current window.
AI-assisted: Claude Code
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)
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.
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.
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>
Problem:
`test/functional/plugin/lsp_spec.lua` had grown into a large catch-all file that mixed core LSP client lifecycle coverage, `vim.lsp.buf.*` behavior, and `vim.lsp.util.*` behavior in one place.
Solution:
Split the large tests into more focused test files without changing test coverage or intended behavior.
After this change, `lsp_spec.lua` is more focused on core LSP client/config/dynamic-registration behavior.
Problem:
The window opened by `vim.lsp.util.open_floating_preview()`
allows its buffer to be switched. Presumably that only happens
by accident and is disorienting.
Solution:
Set 'winfixbuf' in the open_floating_preview() window.
Problem:
To support `collapsedText`, which allows the LSP server to determine the
content of the foldtext, we provided `vim.lsp.foldtext()`. However, such
content does not have highlighting.
Solution
Treat the filetype of `collapsedText` as the filetype of the corresponding
buffer and use tree-sitter to highlight it.
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.
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: 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.
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:
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.
Problem:
Completion preview always assumes plain text, ignoring LSP documentation "kind".
Solution:
Pass markup kind from completion item to info window, or fallback to PlainText.
Problem: `get_doc` throws error with "attempt to get length of a userdata
value" when `item.documentation` is truthy but not a string (e.g. vim.NIL
from a JSON null).
Solution: Check `type(item.documentation)` before taking its length.
Problem: #38169 used compl_used_match to determine the CompleteDone
reason, but this fires too broadly, it also changes the reason to
"accept" when the popup was shown and the user dismissed it with <Esc>
or <Space>, breaking snippet completion with autocomplete.
Solution: Instead of checking compl_used_match in, check whether the pum
was never shown (compl_match_array == NULL) in ins_compl_stop().
When a match was inserted but the pum never displayed,
set the completed word so CompleteDone fires with reason "accept".
This keeps the "discard" reason intact when the user dismisses a visible
pum without confirming.
Problem:
In autocmd examples, using "args" as the event-object name is vague and
may be confused with a user-command.
Solution:
Use "ev" as the conventional event-object name.
Problem:
No completionItem/resolve handler.
Solution:
If completeopt=popup is set, invoke completionItem/resolve when
a completion item is selected. Show resolved documentation in popup next
to the completion menu.
Problem
The logic that clears codelenses beyond the buffer also removes the codelenses on the last line.
Solution
Do not clear the codelens on the last line.
Problem: Color completion items display as plain text without visual preview
Solution: Parse RGB/hex colors from documentation and render with colored symbol ■
Problem:
Regression from b99cdd0:
Pull diagnostics (from `textDocument/diagnostic`) and push diagnostics
(from `textDocument/publishDiagnostics`) use the same namespace, which
is a problem when using language servers that publish two different sets
of diagnostics on push vs pull, like rust-analyzer (see
https://github.com/rust-lang/rust-analyzer/issues/18709#issuecomment-2551394047).
Solution:
Rename `is_pull` to `pull_id` which accepts a pull namespace instead of
just a boolean.
The wait added in #37853 doesn't seem to do anything as request is sent
immediately on InsertLeave, and the number 4 also seems wrong. Instead,
the actual cause for the flakiness that the feed() (and hence the buffer
change) may arrive before the scheduled initialization of capabilities,
causing there be only only one textDocument/semanticTokens/full request
instead of two.
