Previously the LSP-Client object contained some fields that are also
in the client config, but for a lot of other fields, the config was used
directly making the two objects vaguely entangled with either not having
a clear role.
Now the config object is treated purely as config (read-only) from the
client, and any fields the client needs from the config are now copied
in as additional fields.
This means:
- the config object is no longet normalised and is left as the user
provided it.
- the client only reads the config on creation of the client and all
other implementations now read the clients version of the fields.
In addition, internal support for multiple callbacks has been added to
the client so the client tracking logic (done in lua.lsp) can be done
more robustly instead of wrapping the user callbacks which may error.
The dispatchers used by the RPC client should be defined in the client,
so they have been moved there. Due to this, it also made sense to move
all code related to client configuration and the creation of the RPC
client there too.
Now vim.lsp.start_client is significantly simplified and now mostly
contains logic for tracking open clients.
- Renamed client.new -> client.start
Problem: There is no test case for vim.lsp.tagfunc; so CI was unable to
catch the infinite loop bug (#27325).
Solution: Add test cases for vim.lsp.tagfunc().
Use the get_language_id client option to resolve the filetype when
matching the document selector in a dynamic capability.
Co-authored-by: Mathias Fussenegger <f.mathias@zignar.net>
Quick fix as follow up to https://github.com/neovim/neovim/pull/26108
kqueue only reports events on a watched folder itself, not for files
created or deleted within. So the approach the PR took doesn't work on FreeBSD.
We'll either need to bring back polling for it, combine watching with manual
file tracking, or disable LSP file watching on FreeBSD
refactor!: `vim.lsp.inlay_hint()` -> `vim.lsp.inlay_hint.enable()`
Problem:
The LSP specification allows inlay hints to include tooltips, clickable
label parts, and code actions; but Neovim provides no API to query for
these.
Solution:
Add minimal viable extension point from which plugins can query for
inlay hints in a range, in order to build functionality on top of.
Possible Next Steps
---
- Add `virt_text_idx` field to `vim.fn.getmousepos()` return value, for
usage in mappings of `<LeftMouse>`, `<C-LeftMouse>`, etc
Fixes https://github.com/neovim/neovim/issues/25177
I initially wanted to split this into a refactor commit to make it more
testable, but it appears that already accidentally fixed the issue by
normalizing lnum/col to 0-indexing
The haskell-language-server supports resolve only for a subset of code
actions. For many code actions trying to resolve the `edit` property
results in an error, but the unresolved action already contains a
command that can be executed without issue.
The protocol specification is unfortunately a bit vague about this,
and what the haskell-language-server does seems to be valid.
Example:
newtype Dummy = Dummy Int
instance Num Dummy where
Triggering code actions on "Num Dummy" and choosing "Add placeholders
for all missing methods" resulted in:
-32601: No plugin enabled for SMethod_CodeActionResolve, potentially available: explicit-fields, importLens, hlint, overloaded-record-dot
With this change it will insert the missing methods:
instance Num Dummy where
(+) = _
(-) = _
(*) = _
negate = _
abs = _
signum = _
fromInteger = _
Fixes#24339
rust-analyzer sends "Invalid offset" error in such cases. Some other
servers handle it specially.
LSP spec mentions that "A range is comparable to a selection in an
editor". Most editors don't handle trailing newlines the same way
Neovim/Vim does, it's clearly visible if it's present or not. With that
in mind it's understandable why sending end position as simply the start
of the line after the last one is considered invalid in such cases.
PR #23689 assumes `client.config.capabilities.workspace.didChangeWatchedFiles`
exists when checking `dynamicRegistration`, but thats's true only if it was
passed to `vim.lsp.start{_client}`.
This caused #23806 (still an issue in v0.9.1; needs manual backport), but #23681
fixed it by defaulting `config.capabilities` to `make_client_capabilities` if
not passed to `vim.lsp.start{_client}`.
However, the bug resurfaces on HEAD if you provide a non-nil `capabilities` to
`vim.lsp.start{_client}` with missing fields (e.g: not made via
`make_client_capabilities`).
From what I see, the spec says such missing fields should be interpreted as an
absence of the capability (including those indicated by missing sub-fields):
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#clientCapabilities
Also, suggest `vim.empty_dict()` for an empty dict in
`:h vim.lsp.start_client()` (`{[vim.type_idx]=vim.types.dictionary}`
no longer works anyway, probably since the cjson switch).
Previously, filtering code actions with the "only" option failed
if the code action kind contained special Lua pattern chars such as "-"
(e.g. the ocaml language server supports a "type-annotate" code action).
Solution: use string comparison instead of string.find
PROBLEM:
Whenever any text edits are applied to the buffer, the `marks` part of those
lines will be lost. This is mostly problematic for code formatters that format
the whole buffer like `prettier`, `luafmt`, ...
When doing atomic changes inside a vim doc, vim keeps track of those changes and
can update the positions of marks accordingly, but in this case we have a whole
doc that changed. There's no simple way to update the positions of all marks
from the previous document state to the new document state.
SOLUTION:
* save marks right before `nvim_buf_set_lines` is called inside `apply_text_edits`
* check if any marks were lost after doing `nvim_buf_set_lines`
* restore those marks to the previous positions
TEST CASE:
* have a formatter enabled
* open any file
* create a couple of marks
* indent the whole file to the right
* save the file
Before this change: all marks will be removed.
After this change: they will be preserved.
Fixes#14307
If the server sends the positionEncoding capability in its
initialization response, automatically set the client's offset_encoding
to use the value provided.
BREAKING CHANGE: LspRequest is no longer a User autocmd but is now a
first class citizen.
LspRequest as a User autocmd had limited functionality. Namely, the only
thing you could do was use the notification to do a lookup on all the
clients' requests tables to figure out what changed.
Promoting the autocmd to a full autocmd lets us set the buffer the
request was initiated on (so people can set buffer-local autocmds for
listening to these events).
Additionally, when used from Lua, we can pass additional metadata about
the request along with the notification, including the client ID, the
request ID, and the actual request object stored on the client's
requests table. Users can now listen for these events and act on them
proactively instead of polling all of the requests tables and looking
for changes.
- `client.dynamic_capabilities` is an object that tracks client register/unregister
- `client.supports_method` will additionally check if a dynamic capability supports the method, taking document filters into account. But only if the client enabled `dynamicRegistration` for the capability
- updated the default client capabilities to include dynamicRegistration for:
- formatting
- rangeFormatting
- hover
- codeAction
- hover
- rename
Some LSP servers (tailwindcss, rome) are known to request registration
for `workspace/didChangeWatchedFiles` even when the corresponding client
capability does not advertise support. This change adds an extra check
in the `client/registerCapability` handler not to start a watch unless
the client capability is set appropriately.
In the `test_rpc_server` procedure, both `on_setup` and `on_init`
callbacks can run concurrently in some scenarios. This caused some CI
failures in tests for the LSP set_defaults feature.
This commit attempts to fix this by merging those two callbacks in the
impacted tests.
See: https://github.com/neovim/neovim/actions/runs/4553550710/attempts/1
Problem:
When LSP client renames a directory, opened buffers in the edfitor are not
renamed or closed. Then `:wall` shows errors.
https://github.com/neovim/neovim/blob/master/runtime/lua/vim/lsp/util.lua#L776
works correctly if you try to rename a single file, but doesn't delete old
buffers with `old_fname` is a dir.
Solution:
Update the logic in runtime/lua/vim/lsp/util.lua:rename()
Fixes#22617
Sets `NVIM_APPNAME` for the lsp server instances and also for the
`exec_lua` environment to ensure local user config doesn't interfere
with the test cases.
My local `ftplugin/xml.lua` broke the LSP test cases about setting
`omnifunc` defaults.
Problem:
Some built-in ftplugins set omnifunc/tagfunc/formatexpr which causes
lsp.lua:set_defaults() to skip setup of defaults for those filetypes.
For example the C++ ftplugin has:
omnifunc=ccomplete#Complete
Last set from /usr/share/nvim/runtime/ftplugin/c.vim line 30
so the changes done in #95c65a6b221fe6e1cf91e8322e7d7571dc511a71
will always be skipped for C++ files.
Solution:
Overwrite omnifunc/tagfunc/formatexpr options that were set by stock
ftplugin.
Fixes#21001
`vim.lsp.buf.format()` silently did nothing if no servers supported
`textDocument/rangeFormatting` when formatting with a range.
Issue found by `@hwrd:matrix.org` in the Matrix chat.
`willSaveWaitUntil` allows servers to respond with text edits before
saving a document. That is used by some language servers to format a
document or apply quick fixes like removing unused imports.
Extend the capabilities of is_os to detect more platforms such as
freebsd and openbsd. Also remove `iswin()` helper function as it can be
replaced by `is_os("win")`.
This is essentially a convenience wrapper around the `pending()`
function, similar to `skip_fragile()` but more general-purpose.
Also remove `pending_win32` function as it can be replaced by
`skip(iswin())`.
`:saveas newName` changes the name of an existing buffer.
Due to the buffer re-use it skips the lsp attach phase and immediately
sends a `didSave` notification to the server.
Servers get confused about this, because they expect a `didOpen`
notification first.
Closes https://github.com/neovim/neovim/issues/18688
Most LSP servers require the notification to correctly load the
settings and for those who don't it doesn't cause any harm.
So far this is done in lspconfig, but with the addition of vim.lsp.start
it should be part of core.
Cuts down typical run time for `plugin/lsp_spec.lua`
from 70 secs to 12 secs in ASAN CI build.
This happens in ASAN/EXIT_FREE builds where nvim waits 2000ms due to
unclosed handled. I wasn't able to pin-point the exact cause.
But these tests ran in nested context where two server/client pairs
were setup for no good reason. Moving these tests out so only one client
is being setup fixed the exit hang.
The current approach of using `on_attach` callbacks for configuring
buffers for LSP is suboptimal:
1. It does not use the standard Nvim interface for driving and hooking
into events (i.e. autocommands)
2. There is no way for "third parties" (e.g. plugins) to hook into the
event. This means that *all* buffer configuration must go into the
user-supplied on_attach callback. This also makes it impossible for
these configurations to be modular, since it all must happen in the
same place.
3. There is currently no way to do something when a client detaches from
a buffer (there is no `on_detach` callback).
The solution is to use the traditional method of event handling in Nvim:
autocommands. When a LSP client is attached to a buffer, fire a
`LspAttach`. Likewise, when a client detaches from a buffer fire a
`LspDetach` event.
This enables plugins to easily add LSP-specific configuration to buffers
as well as enabling users to make their own configurations more modular
(e.g. by creating multiple LspAttach autocommands that each do
something unique).
Implement filtering of actions based on the kind when passing the 'only'
parameter to code_action(). Action kinds are hierachical with a '.' as
the separator, and the filter thus allows, for example, both 'quickfix'
and 'quickfix.foo' when requestiong only 'quickfix'.
Fix https://github.com/neovim/neovim/pull/18221#issuecomment-1110179121
Adds filter and id options to filter the client to use for rename.
Similar to the recently added `format` function.
rename will use all matching clients one after another and can handle a
mix of prepareRename/rename support. Also ensures the right
`offset_encoding` is used for the `make_position_params` calls
This fixes issues where subsequent calls to vim.lsp.codelens.refresh()
would have no effect due to the buffer not getting cleared from the
active_refresh table.
Examples of how such scenarios would occur are:
- A textDocument/codeLens result yielded an error.
- The 'textDocument/codeLens' handler was overriden in such a way that
it no longer called vim.lsp.codelens.on_codelens().
Deprecates the existing `vim.lsp.buf.formatting` function.
With this, `vim.lsp.buf.format` will replace all three:
- vim.lsp.buf.formatting
- vim.lsp.buf.formatting_sync
- vim.lsp.buf.formatting_seq_sync
* feat(lsp)!: remove capabilities sanitization
Users must now access client.server_capabilities which matches the same
structure as the protocol.
https://microsoft.github.io/language-server-protocol/specification
client.resolved_capabilities is no longer used to gate capabilities, and
will be removed in a future release.
BREAKING CHANGE
Co-authored-by: Mathias Fussenegger <f.mathias@zignar.net>
Implement two new options to vim.lsp.buf.code_action():
- filter (function): predicate taking an Action as input, and returning
a boolean.
- apply (boolean): when set to true, and there is just one remaining
action (after filtering), the action is applied without user query.
These options can, for example, be used to filter out, and automatically
apply, the action indicated by the server to be preferred:
vim.lsp.buf.code_action({
filter = function(action)
return action.isPreferred
end,
apply = true,
})
Fix#17514.
The use of 'softtabstop' to set tabSize was introduced in 5d5b068,
replacing 'tabstop'. If we look past the name tabSize and at the actual
purpose of the field, it's the indentation width used when formatting.
This corresponds to the Vim option 'shiftwidth', not 'softtabstop'.
The latter has the comparatively mundane purpose of controlling what
happens when you hit the tab key (and even this is incomplete, as it
fails to account for 'smarttab').
This removes the "fallback" to utf-16 in many of our helper functions. We
should always explicitly pass these around when possible except in two
locations:
* generating params with help utilities called by buf.lua functions
* the buf.lua functions themselves
Anything that is called by the handler should be passed the offset encoding.
omnisharp-roslyn can send negative values:
{
activeParameter = 0,
activeSignature = -1,
signatures = { {
documentation = "",
label = "TestEntity.TestEntity()",
parameters = {}
} }
}
In 3.16 of the specification `activeSignature` is defined as `uinteger`
and therefore negative values shouldn't be allowed, but within 3.15 it
was defined as `number` which makes me think we can be a bit lenient in
this case and handle them.
The expected behavior is quite clear:
The active signature. If omitted or the value lies outside the
range of `signatures` the value defaults to zero or is ignored if
the `SignatureHelp` has no signatures.
Fixes an error:
util.lua:1685: attempt to get length of local 'lines' (a nil value)
util.lua:1685: in function 'trim_empty_lines'
handlers.lua:334: in function 'textDocument/signatureHelp'
Part of the `pending_change` closure in the `changetracking.prepare` was
a bit confusing because it has access to `bufnr` and `uri` but it could
actually contain pending changes batched for multiple buffers.
(We accounted for that by grouping `pending_changes` by a `uri`, but
it's not obvious what's going on)
This commit changes the approach to do everything per buffer to avoid
any ambiguity.
It also brings the debounce/no-debounce a bit closer together: The
only difference is now whether a timer is used or if it is triggered
immediately
This allows the user to detach an active buffer from the language
client. If no clients remain attached to a buffer, the on_lines callback
is used to cancel nvim_buf_attach.
If a LSP server sent a workspace edit containing a rename the buffers
file name changed without the server receiving a close notification for
the old buffer and without the client properly re-attaching on the new
file.
This affected `Move` code-actions in nvim-jdtls, but also
`vim.lsp.buf.rename` on a class level.
* vim.ui.input is an overridable function that prompts for user input
* take an opts table and the `on_confirm` callback, see `:help vim.ui.input` for more details
* defaults to a wrapper around vim.fn.input(opts)
* switches the built-in client's rename handler to use vim.ui.input by default
Closes https://github.com/neovim/neovim/issues/15174
Instead of invoking handlers with unsupported methods, pre-compute which
clients support a given method and only notify the user if no clients
support the given method.
