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: There is currently no convenient way to programmatically check
for new updates from plugin source. Running `vim.pack.update()` is one
approach, but it opens a confirmation buffer that requires a manual
action to close.
Solution: Add `opts.offline` to `vim.pack.get()` that will first fetch
new updates from plugin source before computing the output.
Problem: No convenient way to programmatically get the revision that
would be checked out after `vim.pack.update()` (with `offline=true`).
Doing this manually requires resolving `spec.version` which is not
trivial. This data can be useful for custom reporting of pending
updates or third party confirmation step.
Solution: Make `get()` include a new field for the revision that points
at the state after applying pending update. This is also the same as
the revision of resolved `spec.version`.
Problem: `vim.pack.get()` always uses lockfile as the source for the
`rev` field. This is fast, but may be misleading in case of
a corrupted lockfile.
Solution: Compute revision from Git repo on disk if `info=true`
(default), use lockfile otherwise. This does increase execution time
(as a result of one extra `git ...` call for every plugin), but
`info=true` is already designed to be informative and not necessarily
fast.
Define `:packupdate` and `:packdel` as separate commands instead of a
unified `:pack {subcommand}` because the semantics between the two
commands vary differently enough that it doesn't make sense to combine
them. Additionally, `:pack! update/del` looks bad.
Problem:
Using the `DiffTool` plugin (e.g. through `nvim -d ...` or `:DiffTool
<file1> <file2>` fails if a space is in one of the paths. This occurs
because the `diff` wraps the paths with quotes (`'`) if space
characters are present, which the line diff regex fails to parse.
Solution:
Update regex to handle quoted paths by matching the string within the
quotes, if it exists.
Problem: Trying to execute code action on an active plugin without
updates leads to nothing. It is more useful if code actions "do
something" on a bigger portion of the confirm buffer.
Solution: Suggest "delete" code action even for active plugins. Trying
to execute it will first show a confirmation buffer with relevant
warning of why this might be not a good idea. Confirming will delete
a plugin.
Problem:
Nested workspace capabilities like workspace.fileOperations.didCreate and
workspace.textDocumentContent are not handled consistently for dynamic and
static registration provider lookup.
Solution:
Generate explicit registration-provider mappings from the LSP metadata and use
them when registering and querying capabilities. Add coverage for dynamic and
static nested workspace registrations.
Problem:
`EBUSY` during cleanup:
Windows CI can intermittently fail `pack_spec.lua` with `EBUSY` while removing
`site/pack/core/opt/plugindirs`.
This can happen because:
- the test Nvim session may still be alive when `after_each()` removes the pack
directory
- Windows does not allow removing a directory while another process still has an
open handle below it
- startup-time `vim.pack.add()` performs a real `git clone`, so process and file
handle release timing can vary on slower runners
Startup timeout:
The startup tests can also fail before cleanup because they wait for `_G.done`
with a fixed timeout. That timeout includes the time needed for startup to run
`vim.pack.add()` and finish the local clone.
Solution:
Close before cleanup:
Capture the pack, lockfile, and log paths while the test Nvim session is still
available, then call `n.check_close()` before removing the pack directory.
Extend Windows startup wait:
Increase the `_G.done` retry budget only on Windows so startup-time
`vim.pack.add()` has more time to finish on slower CI runners.
Problem:
LSP clients previously did not handle dynamic registration for off-spec methods
Solution:
Update the client logic to assume support for dynamic registration when
the method is unknown. Adjust the registration provider fallback and
enhance tests to verify correct behaviour for unknown methods and their
registration options. This improves compatibility with servers using
custom dynamic registrations.
AI-assisted: OpenCode
Problem:
If a buffer's filetype changes after the LSP client has already
attached (e.g. from json to jsonc via a modeline), but the client
supports both filetypes, it stays attached. It does not notify the
server of the new languageId, causing the server to incorrectly process
the file using the old languageId.
Solution:
Save the languageId used during textDocument/didOpen, and send
textDocument/didClose + textDocument/didOpen when buffer's languageId
changed.
Lsp spec:
0003fb53f1/_specifications/lsp/3.18/textDocument/didOpen.md (L5)
> If the language id of a document changes, the client
> needs to send a textDocument/didClose to the server followed by a
> textDocument/didOpen with the new language id if the server handles
> the new language id as well.
AI-assisted: Gemini 3.1 Pro
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: There are many Git forges each with a different way of
constructing permanent links to like commits and tags.
Solution: Add a private utility function that computes these special
links on the best effort basis.
Problem: In `vim.pack.update()` confirmation buffer it might be useful
to be able to use `gx` (open link at cursor) when cursor is on
something like commit or tag.
Solution: Add `textDocument/documentLink` method support for the
in-process LSP. This may be used by LSP clients and makes `gx`
automatically work.
The shortcoming is that this requires tracking how to construct a URL
from source and commit/tag. Currently only GitHub hosted repositories
are supported.
Problem:
The LSP client incorrectly checks for server capabilities when determining
support for self-mapped methods (e.g., 'shutdown'), which do not have
corresponding capabilities in the server's response. This leads to false
negatives when checking if such methods are supported.
This was handled correctly for dynamic registrations, but not for static.
Methods such as 'shutdown', do not have a related server capability and should
be assumed to be supported.
Solution:
Update the `supports_method` logic to always return true for self-mapped
methods.
Problem:
When running nvim on a remote machine over SSH, if there is high ping,
then bg detection may not complete in time. This results in a warning
every time nvim is started. #38648
Solution:
Restore 'ttyfast' option and allow it to control whether or not bg
detection is performed. Because this is during startup and before any
user config or commands, we use the environment variable
`NVIM_NOTTYFAST` to allow disabling `ttyfast` during initialization.
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: Using `version=vim.version.range(...)` in plugin specification
is meant to use semver-like tags. Whether a tag is semver-like was
decided by a plain `vim.version.parse` which is not strict by default.
This allowed treating tags like `nvim-0.6` (which is usually reserved
for the latest revision compatible with Nvim<=0.6 version) like semver
tags and resulted in confusing behavior (preferring `nvim-0.6` tag
over `v0.2.2`, for example).
Solution: Use `vim.version.range(x, { strict = true })` to decide if the
tag name is semver-like or not. This allows tags like both `v1.2.3`
and `1.2.3` while being consistent in what Nvim thinks is a semver
string.
This is technically not a breaking change since it was documented that
only tags like `v<major>.<minor>.<patch>` will be recognized as
semver.
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:
With GIT_DIR/GIT_WORK_TREE set, the LSP on the vim.pack.update()
confirmation buffer does not show the correct git log on hover.
Solution:
Temporarily remove the git vars from the environment.
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: Unreliable test on Windows which sometimes fails with too many
failed retries.
Solution: Increase timeout in hopes that it will be enough to make it
pass more frequently. This should not affect fast and already working
platforms.
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: using `vim.fs.rm(dir_path, { force = true, recursive = true })`
can result in an error on Windows if the process has a handle to it.
Solution: Use `n.rmdir()` helper in cases when its possible side effects
(like changing working directory) does not matter.
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.
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.
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.
