| Commit message (Collapse) | Author | Age |
|---|
| |
|
| |
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
|
| |
|
|
| |
* reformat Lua runtime to make lint CI pass
* reduce max line length to 100
|
| |
|
|
|
|
|
|
|
|
| |
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Co-authored-by: Dan Sully <dan+github@sully.org>
Co-authored-by: saher <msaher.shair@gmail.com>
Co-authored-by: Stephan Seitz <stephan.seitz@fau.de>
Co-authored-by: Benedikt Müller <d12bb@posteo.de>
Co-authored-by: Andrey Mishchenko <mishchea@gmail.com>
Co-authored-by: Famiu Haque <famiuhaque@protonmail.com>
Co-authored-by: Oliver Marriott <hello@omarriott.com>
|
| |
|
|
|
|
|
| |
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().
|
| |
|
|
|
| |
Allow get_active_clients() to filter on client name, id, or buffer. This
(soft) deprecates lsp.buf_get_clients().
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
(#18333)
Co-authored-by: ii14 <ii14@users.noreply.github.com>
|
| |
|
| |
Follow up to https://github.com/neovim/neovim/pull/17814
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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>
|
| | |
|
| |
|
| |
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
|
