Problem:
Closes#31453
Solution:
Introduce `vim.lsp.Capability`, which may serve as the base class for
all LSP features that require caching data. it
- was created if there is at least one client that supports the specific method;
- was destroyed if all clients that support the method were detached.
- Apply the refactor for `folding_range.lua` and `semantic_tokens.lua`.
- Show active features in :checkhealth.
Future:
I found that these features that are expected to be refactored by
`vim.lsp.Capability` have one characteristic in common: they all send
LSP requests once the document is modified. The following code is
different, but they are all for this purpose.
- semantic tokens:
fb8dba413f/runtime/lua/vim/lsp/semantic_tokens.lua (L192-L198)
- inlay hints, folding ranges, document color
fb8dba413f/runtime/lua/vim/lsp/inlay_hint.lua (L250-L266)
I think I can sum up this characteristic as the need to keep certain
data synchronized with the latest version computed by the server.
I believe we can handle this at the `vim.lsp.Capability` level, and
I think it will be very useful.
Therefore, my next step is to implement LSP request sending and data
synchronization on `vim.lsp.Capability`, rather than limiting it to the
current create/destroy data approach.
Problem:
The cancel function returned by `vim.lsp.buf_request` tries to cancel
all the requests, including those that have already been completed,
causing "Cannot find request with id ... whilst attempting to cancel"
errors to be logged when it is called.
Solution:
Only cancel the requests that are present in `client.requests`.
Problem: A custom server (initialized through `vim.lsp.start`) gets
unexpectedly detached.
Solution: Only auto-detach the clients enabled through `vim.lsp.enable`
to prevent unexpected behavior.
Problem:
Stopping a language server and then calling vim.lsp.start() with the same name/root will return the old language server that's in the middle of shutting down. vim.lsp.start() won't return a new server until the old process has terminated.
Solution:
Introducing a client._is_stopping field that tracks the shutdown phase, preventing the client from being reused.
Problem:
enable() routine detaches clients even if they were manually started
and not managed by vim.lsp.config.
Solution:
Skip clients that aren't managed by vim.lsp.config.
Problem:
No way to check if a LSP config is enabled without causing it to
resolve. E.g. `vim.lsp.config['…'] ~= nil` will resolve the config,
which could be an unwanted and somewhat expensive side-effect.
Solution:
Introduce `vim.lsp.is_enabled()`.
Problem:
enable() could be more flexible, so that it works even if called "late".
Solution:
- enable(true) calls `doautoall nvim.lsp.enable FileType`.
- enable(false) calls `client:stop()` on matching clients.
This will be useful for e.g. :LspStop/:LspStart also.
- sort fields alphabetically.
- in the `vim.lsp.Client` docs, reference `vim.lsp.ClientConfig` instead
of duplicating its docs.
- cleanup lots of redundant-yet-drifted field docs.
This change modifies gen_lsp.lua so alias types are generated for
various types of lsp methods to distinguish between notifications
and requests:
- vim.lsp.protocol.Method.ServerToClient.Request
- vim.lsp.protocol.Method.ServerToClient.Notification
- vim.lsp.protocol.Method.ClientToServer.Request
- vim.lsp.protocol.Method.ClientToServer.Notification
These types are then used instead of `string` where appropriate.
Problem:
If a config name contains "*" it causes rtp discovery of `lsp/` to
consider the `*` as a wildcard and could lead to strange and unintended
behaviour. For example, accessing the `'*'` config from a `lsp/` file
would cause an infinite loop.
Solution:
- Explicitly disallow a config name from containing wildcards, with the
exception of `'*'`.
- When Resolving `'*'` config, skip the rtp step.
Problem:
Some language servers do not work properly without a workspace folder.
Solution:
Add `workspace_required`, which skips starting the lsp client if no
workspace folder is found.
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem:
The root dir function is not passed any context and can only assume the
current buffer is the one being attached.
The main use case is for getting the path of the buffer using
`nvim_buf_get_name`.
Solution:
Pass the buffer number as the first argument.
Problem:
Per the documentation, passing `false` as the `enable` parameter of
`vim.lsp.enable()` should disable the given LSP(s), but it does not work
due to a logic error.
Specifically, `enable == false and nil or {}` will always evaluate to
`{}` because `nil` is falsy.
Solution:
Correct the conditional statement.
When `root_dir` is a function it can (and often will) call the provided
callback function in a fast API context (e.g. in the `on_exit` handler
of `vim.system`). When the callback function is executed we should
ensure that it runs vim.lsp.start on the main event loop.
Allows to retrieve the configuration as it will be used by `lsp.enable`
- including the parts merged from `*` and rtp.
This is useful for explicit startup control
(`vim.lsp.start(vim.lsp.config[name])`)
Closes https://github.com/neovim/neovim/issues/31640
