| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LspProgressUpdate (#23958)
`client.messages` could grow unbounded because the default handler only
added new messages, never removing them.
A user either had to consume the messages by calling
`vim.lsp.util.get_progress_messages` or by manually removing them from
`client.messages.progress`. If they didn't do that, using LSP
effectively leaked memory.
To fix this, this deprecates the `messages` property and instead adds a
`progress` ring buffer that only keeps at most 50 messages. In addition
it deprecates `vim.lsp.util.get_progress_messages` in favour of a new
`vim.lsp.status()` and also promotes the `LspProgressUpdate` user
autocmd to a regular autocmd to allow users to pattern match on the
progress kind.
Also closes https://github.com/neovim/neovim/pull/20327
|
| | |
|
| | |
|
| |
|
|
|
|
| |
If the server sends the positionEncoding capability in its
initialization response, automatically set the client's offset_encoding
to use the value provided.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
data (#23694)
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
|
| |
|
|
|
| |
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Co-authored-by: famiu <famiuhaque@protonmail.com>
|
| |
|
|
|
|
|
|
|
| |
Co-authored-by: Christian Clason <c.clason@uni-graz.at>
Co-authored-by: Gregory Anders <greg@gpanders.com>
Co-authored-by: HiPhish <hiphish@posteo.de>
Co-authored-by: Julio B <julio.bacel@gmail.com>
Co-authored-by: T727 <74924917+T-727@users.noreply.github.com>
Co-authored-by: camoz <camoz@users.noreply.github.com>
Co-authored-by: champignoom <66909116+champignoom@users.noreply.github.com>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* feat(lua): vim.tbl_contains supports general tables and predicates
Problem: `vim.tbl_contains` only works for list-like tables (integer
keys without gaps) and primitive values (in particular, not for nested
tables).
Solution: Rename `vim.tbl_contains` to `vim.list_contains` and add new
`vim.tbl_contains` that works for general tables and optionally allows
`value` to be a predicate function that is checked for every key.
|
| |
|
|
| |
Now that we have builtin EditorConfig support and a formatting check in
CI, these are not necessary.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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' };
})
|
