| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
| |
Also, don't start the timer at all when a previous shutdown failed, as
in this case a forced shutdown is used and no timer is needed.
This fixes most of the delays caused by #36750.
The delays caused by #36378 still seem to remain.
|
| |
|
|
|
|
|
|
| |
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:
Nvim supports `textDocument/semanticTokens/full` and `…/full/delta`
already, but most servers don't support `…/full/delta` and Nvim will try
to request and process full semantic tokens response on every buffer
change. Even though the request is debounced, there is noticeable lag if
the token response is large (in a big file).
Solution:
Support `textDocument/semanticTokens/range`, which requests semantic
tokens for visible screen only.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
- mention "lua_ls", not "luals". https://github.com/neovim/neovim/discussions/36182
Co-authored-by: Maria Solano <majosolano99@gmail.com>
|
| |
|
|
|
| |
where appropriate. (#36180)
fix(lsp): replace `string` types with LSP method alias where appropriate
|
| |
|
|
|
|
|
| |
function" #36183
This reverts commit 97ab24b9c7d9327740f0692f8076fed5737a52dc.
See discussion in https://github.com/neovim/neovim/pull/36071
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a regression from #33796.
I tried for several hours and cannot write a working test for this, but
this does fix the following warning in tests run with ASAN or TSAN:
-------- Running tests from test/functional/plugin/lsp_spec.lua
RUN T4667 LSP server_name specified start_client(), stop_client(): 114.00 ms OK
RUN T4668 LSP server_name specified stop_client() also works on client objects: 97.00 ms OK
RUN T4669 LSP server_name specified does not reuse an already-stopping client #33616: 31.00 ms OK
nvim took 2022 milliseconds to exit after last test
This indicates a likely problem with the test even if it passed!
|
| |
|
|
|
|
|
| |
Problem: The registerCapability handler re-enables document_color,
making it impossible to disable it in LspAttach.
Solution: Enable it once on initialization and avoid re-enabling
on registerCapability.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
lsp._capability.is_enabled() can raise error if buffer is invalid in client:on_attach().
- error
```
./build/bin/nvim --clean --headless +"source ./minimal.lua"
vim.schedule callback: ...omo/workspace/neovim/runtime/lua/vim/lsp/_capability.lua:209: scoped variable: Invalid buffer id: 2
stack traceback:
[C]: in function '__index'
...omo/workspace/neovim/runtime/lua/vim/lsp/_capability.lua:209: in function 'is_enabled'
...e/notomo/workspace/neovim/runtime/lua/vim/lsp/client.lua:1108: in function <...e/notomo/workspace/neovim/runtime/lua/vim/lsp/client.lua:1101>
```
- reproduction minimal.lua
```lua
vim.opt.runtimepath:append("/path/to/nvim-lspconfig/")
vim.lsp.enable("lua_ls")
vim.cmd.tabedit("runtime/lua/vim/_defaults.lua")
vim.api.nvim_create_autocmd({ "LspAttach" }, {
group = vim.api.nvim_create_augroup("test", {}),
callback = function()
vim.cmd.tabedit("runtime/lua/vim/_defaults.lua")
local bufnr = vim.api.nvim_get_current_buf()
vim.api.nvim_buf_delete(bufnr, { force = true })
end,
})
```
Solution:
Check whether buffer is valid.
|
| |
|
|
|
|
|
|
|
|
| |
Implements [on-type
formatting](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.18/specification/#textDocument_onTypeFormatting)
using a `vim.on_key()` approach to listen to typed keys. It will listen
to keys on the *left hand side* of mappings. The `on_key` callback is
cleared when detaching the last on-type formatting client. This feature
is disabled by default.
Co-authored-by: Maria José Solano <majosolano99@gmail.com>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
Previously, 'null' value in LSP responses were decoded as 'nil'.
This caused ambiguity for fields typed as '? | null' and led to
loss of explicit 'null' values, particularly in 'data' parameters.
Solution:
Decode all JSON 'null' values as 'vim.NIL' and adjust handling
where needed. This better aligns with the LSP specification,
where 'null' and absent fields are distinct, and 'null' should
not be used to represent missing values.
This also enables proper validation of response messages to
ensure that exactly one of 'result' or 'error' is present, as
required by the JSON-RPC specification.
|
| | |
|
| | |
|
| | |
|
| |
|
| |
ref: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_linkedEditingRange
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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:
https://github.com/neovim/neovim/blob/fb8dba413f2bcaa61c15d1854b28112e3e91a035/runtime/lua/vim/lsp/semantic_tokens.lua#L192-L198
- inlay hints, folding ranges, document color
https://github.com/neovim/neovim/blob/fb8dba413f2bcaa61c15d1854b28112e3e91a035/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:
In LSP configs, the function form of `cmd()` cannot easily get the
resolved root dir (workspace). One of the main use-cases of a dynamic
`cmd()` is to be able to start a new server whose binary may be located
*in the workspace* ([example](https://github.com/neovim/nvim-lspconfig/pull/3912)).
Compare `reuse_client()`, which also receives the resolved config.
Solution:
Pass the resolved config to `cmd()`.
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
|
| | |
|
| | |
|
| |
|
|
| |
Type fixes caught by emmylua
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
- 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.
|
| |
|
| |
Co-authored-by: Maria José Solano <majosolano99@gmail.com>
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
In cases when the (in-process) LSP server responds to the request
immediately and calls `notify_reply_callback` the request will still be
marked as pending, because the code assumes that the response will occur
asynchronously. Then the request will be pending forever, because it was
already set as "completed" before we even set it as "pending".
A workaround is to wrap `notify_replay_callback` in `vim.shedule` ([like
so](https://github.com/neovim/neovim/pull/24338#issuecomment-2809568617)]
but that seems counterintuitive.
Solution:
Handle this case in Client:request().
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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:
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>
|
| | |
|
| | |
|
