Although using `buffer://` for unsaved file buffers fixes issues with
language servers like eclipse.jdt.ls or ansible-language-server, it
breaks completion and signature help for clangd.
A regression is worse than a fix for something else, so this reverts
commit 896d672736.
The spec change is also still in dicussion, see
https://github.com/microsoft/language-server-protocol/pull/1679#discussion_r1130704886
* Also fix newly found type mismatch.
* Note that it generates new warnings about using @private client
methods. A proper fix would be to revamp the lsp client documentation
altogether.
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
If the LSP server fails to start then the client never initializes and
thus never calls its on_attach function and an LspAttach event is
never fired. However, the on_exit function still fires a LspDetach
event, so user autocommands that attempt to "clean up" in LspDetach may
run into problems if they assume that the buffer was already attached.
The solution is to only fire an LspDetach event if the buffer was
already attached in the first place.
Small, but I was getting warnings about my usage of
`vim.lsp.buf_notify(bufnr, method, {example = example})` since the docs
say that `params` must be a string, however this can really be anything
when it's passed to `rpc.notify` since we just end up calling
`vim.json.encode(payload)` on it. This fixes the docs in those two
places and regenerates them.
1. The algorithm for applying edits was slightly incorrect. It needs to
preserve the original token list as the edits are applied instead of
mutating it as it iterates. From the spec:
Semantic token edits behave conceptually like text edits on
documents: if an edit description consists of n edits all n edits are
based on the same state Sm of the number array. They will move the
number array from state Sm to Sm+1.
2. Schedule the semantic token engine start() call in the
client._on_attach() function so that users who schedule_wrap() their
config.on_attach() functions (like nvim-lspconfig does) can still
disable semantic tokens by deleting the semanticTokensProvider from
their server capabilities.
* credit to @smolck and @theHamsta for their contributions in laying the
groundwork for this feature and for their work on some of the helper
utility functions and tests
`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.
The execution of the LspDetach autocommands in the LSP client's on_exit
function are scheduled on the event loop to avoid making API calls in a
fast context; however, this means that by the time the LspDetach
autocommands finally run the client object has already been deleted.
To address this, we also schedule the deletion of the client on the
event loop so that it is guaranteed to occur after all of the LspDetach
autocommands have fired.
This starts a soft phase-out of `buf_request`.
`buf_request` is quite error prone:
- Positional `params` depend on the client because of the
`offset_encoding`. Currently if there is one client using UTF-8 offset
encoding and another using UTF-16, the positions in the request are
wrong for one of the clients. To solve this the params would need to
be created per client instead of once for all of them.
- `handler` is called *per* client but many users of it assume it is
only called once.
This can lead to a "select n + 1"
kind of problem, where the handler makes another call to `buf_request`,
multiplying the amount of requests.
(There are in fact still some places where this happens in core)
Or it leads to erratic behavior if called multiple times (E.g. the
quicklist list flickering & being overwritten)
(See hover or references implementation)
`buf_request_all` returns an aggregate of the responses which is more
sensible as it avoids this problem.
For off-spec extensions it also has the problem that it sends requests to
clients which cannot handle a given request.
Given that `buf_request` is in use by a lot of plugins this starts a
soft-phase out. Planned Steps:
- Remove from docs
- Provide an alternative, either `buf_request_all`, maybe with
extensions (params being a function), or an entirely new method.
- Mark as deprecated in 0.9
- Remove in 0.10
To note:
- `buf_request_all` currently isn't ideal either because it suffers from
the `params` problem as well.
- This implies that the `vim.lsp.with` pattern will die, because the
global handlers as they are don't fit a multi-client model, as most of
the time an aggregate is needed.
`server_capabilities` can be nil until the server is initialized.
Reproduced with:
vim.lsp.stop_client(vim.lsp.start_client {
cmd = { vim.v.progpath, '-es', '-u', 'NONE', '--headless' };
})
The change tracking used a single lines/lines_tmp table to track
changes to a buffer.
If multiple clients using incremental sync are connected to a buffer,
they both made changes to the same lines table. That resulted in an
inconsistent state.
This commit changes the didChange handling to group clients by
synchronization scheme and offset encoding.
This avoids computing the diff multiple times for clients using the
same scheme and resolves the lines/lines_tmp conflicts.
Fixes https://github.com/neovim/neovim/issues/19325
The lsp client used to wait up to 500ms for a language server to
shutdown before sending a TERM signal.
The intention behind the 500ms grace period was to ensure the language
server exits to prevent stale processes, but it has the side-effect that
it can interrupt language-servers which are too slow to shutdown within
500ms. Language servers tend to write out index files or project files
on shutdown, and being interrupted during this process can cause
corruption of those files.
This changes the default to not wait at all, at the risk of leaving
stale processes around if the language server isn't well behaved.
An alternative would be to wait indefinitely, but that can cause neovim
to take several seconds to exit.
`: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
vim.lsp.start_client() may fail (for example if the `cmd` is not
executable). It produces a nice error notification in this case. Passing
the `nil` value returned from an erroneous `vim.lsp.start_client()` call
into `vim.lsp.buf_attach_client()` causes a meaty param validate
exception message. Avoid this.
Issuing a server request triggers `changetracking.flush` so as to
make sure we're not operating on a stale state. This immediately
triggers notification of any pending changes (as a result of debouncing)
to the server. However, this happens in addition to the notification
that is waiting on the debounce delay. Because we `nil`
`buf_state.pending_change` when it is called, the fix is to
also check that this is non-`nil` when it is called and exit if it is,
as this being `nil` would mean that it originates from a pending change
that has already been flushed out.
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.
A alternative/subset of https://github.com/neovim/neovim/pull/18506 that should be forward compatible with a potential project system.
Configuration of LSP clients (without lspconfig) now looks like this:
vim.lsp.start({
name = 'my-server-name',
cmd = {'name-of-language-server-executable'},
root_dir = vim.fs.dirname(vim.fs.find({'setup.py', 'pyproject.toml'}, { upward = true })[1]),
})
The client state is cleaned up both in client.stop() as well as in the
client.on_exit() handler. Technically, the client has not actually
stopped until the on_exit handler is called, so we should just do this
cleanup there and remove it from client.stop().
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).
LSP servers should be daemonized (detached) so that they run in a
separate process group from Neovim's. Among other things, this ensures
the process does not inherit Neovim's TTY (#18475).
Make this configurable so that clients can explicitly opt-out of
detaching from Nvim.
* 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>
LSP server might return an item which would replace a token to another.
For example in typescript for a `jest.Mock` object `getProductsMock.`
text I get the following response:
```
{
commitCharacters = {
".",
",",
"("
},
data = {
entryNames = {
"Symbol"
},
file = "/foo/bar/baz.service.spec.ts",
line = 268,
offset = 17
},
filterText = ".Symbol",
kind = 6,
label = "Symbol",
sortText = "11",
textEdit = {
newText = "[Symbol]",
range = {
end = {
character = 16,
line = 267
},
start = {
character = 15,
line = 267
}
}
}
},
```
In `lsp.omnifunc` to get a `prefix` we call the `adjust_start_col` which
then returns the `textEdit.range.start.character`.
Th `prefix` then be the `.` character. Then when filter the items with
`remove_unmatch_completion_items`, every item will be filtered out,
since no completion word starts `.`.
To fix we return the `end.character`, which in that particular case will
be the position after the `.`.
This commits introduces two performance improvements in incremental sync:
* avoiding expensive lua string reallocations on each on_lines call by requesting
only the changed chunk of the buffer as reported by firstline and new_lastline
parameters of on_lines
* re-using already allocated tables for storing the resulting lines to reduce the load on
the garbage collector
The majority of the performance improvement is from requesting only changed chunks
of the buffer.
Benchmark:
The following code measures the time required to perform a buffer edit to
that operates individually on each line, common to plugins such as vim-commentary.
set rtp+=~/.config/nvim/plugged/nvim-lspconfig
set rtp+=~/.config/nvim/plugged/vim-commentary
lua require('lspconfig')['ccls'].setup({})
function! Benchmark(tries) abort
let results_comment = []
let results_undo = []
for i in range(a:tries)
echo printf('run %d', i+1)
let begin = reltime()
normal gggcG
call add(results_comment, reltimefloat(reltime(begin)))
let begin = reltime()
silent! undo
call add(results_undo, reltimefloat(reltime(begin)))
redraw
endfor
let avg_comment = 0.0
let avg_undo = 0.0
for i in range(a:tries)
echomsg printf('run %3d: comment=%fs undo=%fs', i+1, results_comment[i], results_undo[i])
let avg_comment += results_comment[i]
let avg_undo += results_undo[i]
endfor
echomsg printf('average: comment=%fs undo=%fs', avg_comment / a:tries, avg_undo / a:tries)
endfunction
command! -bar Benchmark call Benchmark(10)
All text changes will be recorded within a single undo operation. Both the
comment operation itself and the undo operation will generate an on_lines event
for each changed line. Formatter plugins using setline() have also been found
to exhibit the same problem (neoformat, :RustFmt in rust.vim), as this function
too generates an on_lines event for every line it changes.
Using the neovim codebase as an example (commit 2ecf0a4)
with neovim itself built at 2ecf0a4 with
CMAKE_BUILD_TYPE=Release shows the following performance improvement:
src/nvim/lua/executor.c, 1432 lines:
- baseline, no optimizations: comment=0.540587s undo=0.440249s
- without double-buffering optimization: comment=0.183314s undo=0.060663s
- all optimizations in this commit: comment=0.174850s undo=0.052789s
src/nvim/search.c, 5467 lines:
- baseline, no optimizations: comment=7.420446s undo=7.656624s
- without double-buffering optimization: comment=0.889048s undo=0.486026s
- all optimizations in this commit: comment=0.662899s undo=0.243628s
src/nvim/eval.c, 11355 lines:
- baseline, no optimizations: comment=41.775695s undo=44.583374s
- without double-buffering optimization: comment=3.643933s undo=2.817158s
- all optimizations in this commit: comment=1.510886s undo=0.707928s
Co-authored-by: Dmytro Meleshko <dmytro.meleshko@gmail.com>
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
Follow up to https://github.com/neovim/neovim/pull/16881
Document changes could get sent out of order to the server:
1. on_lines: debounce > 0; add to pending changes; setup timer
2. on_lines: debounce = 0; send new changes immediately
3. timer triggers, sending changes from 1.
The idea of the debounce is to avoid overloading a server with didChange
notifications. So far this used a constant value to group changes within
an interval together and send a single notification. A side effect of
this is that when you were idle, notifications are still delayed.
This commit changes the logic to take the time the last notification
happened into consideration, if it has been greater than the debounce
interval, the debouncing is skipped or at least reduced.
Co-authored-by: Sean Dewar <seandewar@users.noreply.github.com>
Co-authored-by: Gregory Anders <greg@gpanders.com>
Co-authored-by: Sebastian Volland <seb@baunz.net>
Co-authored-by: Lewis Russell <lewis6991@gmail.com>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
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.
Closes https://github.com/neovim/neovim/issues/16562https://github.com/neovim/neovim/issues/16249https://github.com/neovim/neovim/issues/16297
* buf_attach_client can be called on an unloaded buffer
* on_attach will prematurely fail, while the language server client
tracks this buffer as attached
* The language server client will track this buffer as attached despite
textDocument/didChange notifications not being sent to the server
* Instead, check if the buffer is loaded and return early, warning via
the lsp logger that buf_attach_client was called on an invalid buffer
The on_exit handler provided to the client configuration is called after
the client's context is cleared (e.g. which buffers the client was
attached to). Calling the handler sooner allows these handlers to access
the client object and do their own cleanup with the full context.
Previously, the built-in language server client checked if the first
argument of cmd was executable via vim.fn.executable. This ignores PATH
injected via cmd_env. Instead, we now start the client via uv.spawn, and
handle the failure mode, reporting the error back to the user.
Co-authored-by: Mathias Fußenegger <mfussenegger@users.noreply.github.com>
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.
* use codeunits/points instead of byte ranges when applicable
* take into account different file formats when computing range and
sending text (dos, unix, and mac supported)
* add tests of incremental sync
Fixes a bug introduced by https://github.com/neovim/neovim/pull/15949
When no supported clients for a given method are available, buf_request
returns early with a nil value. If buf_request_sync is called on a
buffer with no clients that support a given method, the returned
`cancel` method (which is nil), is invoked, resulting in an error.
Solution: return an empty function handle
* This flag allows customizing the time before sending kill -15 to the
server. If set to false, neovim exits immediately after sending
request('shutdown'). Otherwise, polls until all servers have shutdown,
and then kills remaining servers via kill -15 at exit_timeout
duration. Defaults to 500 ms.
closes https://github.com/neovim/neovim/issues/16058
* add client.attached_buffers
* only update client.attached_buffers in on_attach
* use table instead of list for attached_buffers to avoid duplication
