The auto-refresh has a bit of a delay so it can happen that when a user
runs `codelens.run` it operates on an outdated state and either
does nothing, or fails.
This changes the logic for `.run` to always fetch the current lenses
before (optional) prompt and execution.
See discussion in https://github.com/neovim/neovim/pull/37689#discussion_r2764235931
This could potentially be optimized to first check if there's local
state with a version that matches the current buf-version, but in my
testing re-fetching them always was quickly enough that `run` still
feels instant and doing it this way simplifies the logic.
Side effect of the change is that `.run` also works if codelens aren't
enabled - for power users who know what the codelens would show that can
be useful.
Problem:
If `vim.lsp.enable()` fails with an error, either because `'*'` is one
of the provided names or because there is an error in a config,
`vim.lsp.enable()` will still have side-effects:
- All names before the one that encountered an error will still be added
to `lsp._enabled_configs`, but the autocommand will not get added or
run.
- Any name which makes `vim.lsp.config[name]` error will be added to
`lsp._enabled_configs`, causing all future calls to `vim.lsp.enable()`
to fail. This will also break `:che vim.lsp`.
Solution:
- Check all names for errors before modifying `lsp._enabled_configs`.
- Check `vim.lsp.config[name]` does not raise an error before enabling
the name.
* cache all tokens from various range requests for a given document
version
- all new token highlights are merged with previous highlights to
maintain order and the "marked" property
- this allows the tokens to stop flickering once they've loaded once
per document version
* abandon the processing coroutine if the request_id has changed instead
of relying only on the document version
- this will improve efficiency if a new range request is made while a
previous one was processing its result
* apply new highlights from processing coroutine directly to the current
result when the version hasn't changed
- this allows new highlights to be immediately drawable once they've
processed instead of waiting for the whole response to be processed
at once
* rpc layer was changed to provide the request ID back in success
callbacks, which is then provided as a request_id field on the handler
context to lsp handlers
Problem:
`:lsp restart` detects when a client has exited by using the `LspDetach`
autocommand. This works correctly in common cases, but breaks when
restarting a client which is not attached to any buffer. It also breaks
if a client is detached in between `:lsp restart` and the actual
stopping of the client.
Solution:
Move restart logic into `vim/lsp/client.lua`, so it can hook in to
`_on_exit()`. The public `on_exit` callback cannot be used for this, as
`:lsp restart` needs to ensure the restart only happens once, even if
the command is run multiple times on the same client.
Problem:
`on_accept` is a bit cumbersome to customize.
Solution:
* Before: users had to override the entire `on_accept` logic for their changes to be applied.
* Now: users can modify the item and return it to apply the modified changes, or return `nil` to fully customize how the changes are applied.
Problem:
- Despite [nvim-lspconfig](https://github.com/neovim/nvim-lspconfig)
claims to be a "data-only" plugin, in fact it still provides some
user-facing commands because they haven't been upstreamed to Nvim.
Solution:
- Upstream `:LspRestart`, `:LspStart` and `:LspStop` commands as `:lsp
restart`, `:lsp start` and `:lsp stop` respectively.
Co-authored-by: glepnir <glephunter@gmail.com>
Problem:
Our LSP type system didnt have a concept of RegistrationMethods, this is where the method to dynamically register for a capability is sent to a different method endpoint then is used to call it. Eg `textDocument/semanticTokens` rather than the specific full/range/delta methods
Solution:
Extended generator to create `vim.lsp.protocol.Methods.Registration` with these registration methods. Also extend `_request_name_to_client_capability` to cover these methods. Adjust typing to suit
Problem:
If a `vim.lsp.config` explicitly sets `exit_timeout`, that indicates the
config wants that behavior for most usages of `:stop()`.
Solution:
Update `:stop()` to use `force=exit_timeout` if `force` was not
explicitly passed.
Problem:
The `flags` field calls its sub-fields "experimental".
But `exit_timeout` is now used for multiple purposes.
Solution:
Graduate `exit_timeout` to a top-level ClientConfig field.
Problem:
LSP server may not exit even after the client was stopped/disabled via enable(false).
Solution:
Automatically force-stop after a timeout, unless `client.flags.exit_timeout = false`.
Problem:
LSP incremental selection provides default visual-mode keymaps for `an`
and `in`. Operator-pending mode is not supported, so `dan` and `can` do
not apply the operation.
Solution:
Modify selection_range() to be synchronous.
Add operator-pending mappings.
Problem: No way to customize completion order across multiple servers.
Solution: Add `cmp` function to `vim.lsp.completion.enable()` options
for custom sorting logic.
docs(lsp): specify exactly how `vim.lsp.config` merges configs…
Problem:
It already says that the behaviour is defined by `vim.tbl_deep_extend`,
but that can mean very different things depending on the `behavior`
parameter.
Solution:
Specify that it uses "force".
* fix(lsp): type of root_dir should be annotated with string|fun|nil
* feat(lsp): support root_dir as function in _get_workspace_folders
* feat(lsp): let checkhealth support root_dir() function
Examples:
vim.lsp: Active Clients ~
- lua_ls (id: 1)
- Version: <Unknown>
- Root directories:
~/foo/bar
~/dev/neovim
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem: example code refers to `vim.lsp.buf.document_color`, but there
is no such thing.
Solution: replace `vim.lsp.buf.document_color` with `vim.lsp.document_color`.
- Problem: It's not clear for new plugin developers that `:help` uses
a help-tags file for searching the docs, generated by `:helptags`.
- Solution: Hint to the |:helptags| docs for regenerating the tags
file for their freshly written documentation.
Co-authored-by: Yochem van Rosmalen <git@yochem.nl>
