| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Subset of https://github.com/neovim/neovim/pull/22407 that was reverted
in https://github.com/neovim/neovim/pull/22604
If a buffer is renamed sending `didClose` for the old buffer helps
ensure the language server doesn't keep a stale document in memory.
|
| |
|
|
|
|
|
|
|
|
|
| |
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 896d672736b32a8f4a4fa51844b44f266dcdcc6c.
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.
|
| |
|
|
|
|
| |
Sending `didOpen` with a `file` scheme causes problems with some
language servers because they expect the file to exist on disk.
See https://github.com/microsoft/language-server-protocol/pull/1679
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
| |
docs(lsp): format arguments to start_client()
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
(#21624)
|
| |
|
| |
Fixes https://github.com/neovim/neovim/issues/21523
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
(#20551)
|
| | |
|
| |
|
|
|
| |
Fix those naughty single quotes.
closes #20159
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
Co-authored-by: Mathias Fussenegger <f.mathias@zignar.net>
|
| | |
|
| |
|
|
|
| |
To prepare for different transports like TCP where the handle won't have
a kill method.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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' };
})
|
| |
|
| |
Follow up to https://github.com/neovim/neovim/pull/19658
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
Follow up to https://github.com/neovim/neovim/pull/19003
|
| |
|
|
| |
The last line was excluded from formatting via formatexpr because the
character in the params was set to 0 instead of the end of line.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
* refactor(lsp): use autocmd api
* refactor(lsp): inline BufWritePost and VimLeavePre callbacks
|
| | |
|
| | |
|
| |
|
| |
Fixes #19326
|
| |
|
|
|
|
|
| |
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.
|
| |
|
| |
set `tagfunc` to `vim.lsp.tagfunc` and `omnifunc` to `vim.lsp.omnifunc` if empty when attaching a server
|
