Previously the LSP-Client object contained some fields that are also
in the client config, but for a lot of other fields, the config was used
directly making the two objects vaguely entangled with either not having
a clear role.
Now the config object is treated purely as config (read-only) from the
client, and any fields the client needs from the config are now copied
in as additional fields.
This means:
- the config object is no longet normalised and is left as the user
provided it.
- the client only reads the config on creation of the client and all
other implementations now read the clients version of the fields.
In addition, internal support for multiple callbacks has been added to
the client so the client tracking logic (done in lua.lsp) can be done
more robustly instead of wrapping the user callbacks which may error.
The dispatchers used by the RPC client should be defined in the client,
so they have been moved there. Due to this, it also made sense to move
all code related to client configuration and the creation of the RPC
client there too.
Now vim.lsp.start_client is significantly simplified and now mostly
contains logic for tracking open clients.
- Renamed client.new -> client.start
Problem:
If a rename results in a path that has missing parent directory(s), it
will fail.
Solution:
Do a recursive mkdir before attempting the rename.
Problem:
`vim.lsp.diagnostic.on_diagnostic` accepts an undocumented severity_limit
option which is widely used.
Solution:
Deprecate it in favour of `{min = severity}` used in `vim.diagnostic`.
Since this is undocumented, the schedule for removal is accelerated to
0.11.
Problem:
The LSP client code is implemented as a complicated closure-class
(class defined in a single function).
Solution:
Move LSP client code to a more conventional Lua class and move to a
separate file.
Problem: vim.lsp.tagfunc() causes an infinite loop.
This is a bug happened while introducing deferred loading.
Solution: Rename the private module to `vim.lsp._tagfunc`.
The benefit of this is that users only pay for what they use. If e.g.
only `vim.lsp.buf_get_clients()` is called then they don't need to load
all modules under `vim.lsp` which could lead to significant startuptime
saving.
Also `vim.lsp.module` is a bit nicer to user compared to
`require("vim.lsp.module")`.
This isn't used for some nested modules such as `filetype` as it breaks
tests with error messages such as "attempt to index field 'detect'".
It's not entirely certain the reason for this, but it is likely it is
due to filetype being precompiled which would imply deferred loading
isn't needed for performance reasons.
This function is used only in the `workspace/configuration` handler,
and does not warrant a public API because of its confusing return types.
The only caller `vim.lsp.handlers["workspace.configuration"]` is also
refactored to use `vim.tbl_get()` instead.
Typings introduced in #26032 and #26552 have a few conflicts, so we
merge and clean them up. We also fix some incorrect type annotation in
the `vim.lsp.rpc` package. See the associated PR for more details.
Summary:
- vim.rpc.Dispatchers -> vim.lsp.rpc.Dispatchers
- vim.lsp.rpc.Error -> lsp.ResponseError
- Revise docs
Problem:
Currently `deepcopy` hashes every single tables it copies so it can be
reused. For tables of mostly unique items that are non recursive, this
hashing is unnecessarily expensive
Solution:
Port the `noref` argument from Vimscripts `deepcopy()`.
The below benchmark demonstrates the results for two extreme cases of
tables of different sizes. One table that uses the same table lots of
times and one with all unique tables.
| test | `noref=false` (ms) | `noref=true` (ms) |
| -------------------- | ------------------ | ----------------- |
| unique tables (50) | 6.59 | 2.62 |
| shared tables (50) | 3.24 | 6.40 |
| unique tables (2000) | 23381.48 | 2884.53 |
| shared tables (2000) | 3505.54 | 14038.80 |
The results are basically the inverse of each other where `noref` is
much more performance on tables with unique fields, and `not noref` is
more performant on tables that reuse fields.
This reverts commit 5cb906e91c.
They were intentionally fast-tracked.
- `parse_snippet()` because of limited scope, and given that it's kinda
semi-broken (arbitrary formatting rules, not that useful for what it
was used for)
- `extract_completion_items()` doesn't work if we want to add the LSP
completionlist capability
- `text_document_completion_list_to_complete_items()` also doesn't work
for completionlist
Style improvements:
1. Anonymous classes derived from `StructureLiteralType` should have a
better name. The class name can be also nested. Examples:
```diff
----@field serverInfo? anonym1
+---@field serverInfo? lsp._anonym1.serverInfo
```
```diff
----@field insertTextModeSupport? anonym26
+---@field insertTextModeSupport? lsp._anonym26.completionItem.insertTextModeSupport
```
2. Add one separate empty line before each `@field` definition. Without
these, empty lines the doc can look confusing because descriptions
also may contain empty lines. See `lsp.CompletionItem` for example:
```lua
---The kind of this completion item. Based of the kind
---an icon is chosen by the editor.
---@field kind? lsp.CompletionItemKind
---Tags for this completion item.
---
---@since 3.15.0
---@field tags? lsp.CompletionItemTag[]
```
It might feel like "Tags for this completion item" belongs to `kind`,
not `tags` due to the lack of separator blank lines. The following
(after this commit) should look much better:
```diff
---The kind of this completion item. Based of the kind
---an icon is chosen by the editor.
---@field kind? lsp.CompletionItemKind
+---
---Tags for this completion item.
---
---@since 3.15.0
---@field tags? lsp.CompletionItemTag[]
```
3. Escape some LSP-specific annotations that can't be recognized by
lua-ls. It'd be better to make them visible in LSP hover doc windows.
Example: `@sample ...`.
Fixes:
1. A type may extend from more than one base types (as well as mixin
types). Previously only the first base class was being considered,
resulting incomplete base classes for `@class` definitions.
Example: `InlayHintOptions` (should have both of `resolveProvider`
and `workDoneProgress`, the latter is from `WorkDoneProgressOptions`)
```diff
----@class lsp.InlayHintOptions
+---@class lsp.InlayHintOptions: lsp.WorkDoneProgressOptions
```
2. Remove `<200b>` (zero-width space) unicode characters.
3. Add the missing newline at EOF.
The purpose of this commit is to make diff clean and easy to read; to
see the diff resulted from actual changes in gen_lsp.lua, not from the
updated LSP protocol JSON data.
Ran: `nvim -l scripts/gen_lsp.lua gen --methods`
Based on 3.18.0 (2023-12-23)
The following functions should be removed in 0.12 according to the
deprecation strategy in MAINTAIN.md:
- vim.lsp.util.extract_completion_items()
- vim.lsp.util.parse_snippet()
- vim.lsp.util.text_document_completion_list_to_complete_items()
Use the get_language_id client option to resolve the filetype when
matching the document selector in a dynamic capability.
Co-authored-by: Mathias Fussenegger <f.mathias@zignar.net>
refactor(lsp): move glob parsing to vim.glob
Moving the logic for using vim.lpeg to create a match pattern from a
glob into `vim.glob`. There are several places in the LSP spec that
use globs, and it's very useful to have glob matching as a
generally-available utility.
- Improve CLI argument parsing, rejects invalid argument and commands as
early as possible. Also prints USAGE in the command line.
- No longer allows `--<outfile>`, use `--out <outfile>` instead.
- Print a little bit of verbose messages to better know what's going on
rather than remaining silent at all times.
- Add type annotation `gen_lsp._opt` to avoid type warnings.
refactor!: `vim.lsp.inlay_hint()` -> `vim.lsp.inlay_hint.enable()`
Problem:
The LSP specification allows inlay hints to include tooltips, clickable
label parts, and code actions; but Neovim provides no API to query for
these.
Solution:
Add minimal viable extension point from which plugins can query for
inlay hints in a range, in order to build functionality on top of.
Possible Next Steps
---
- Add `virt_text_idx` field to `vim.fn.getmousepos()` return value, for
usage in mappings of `<LeftMouse>`, `<C-LeftMouse>`, etc
`code_action` used the same parameters for all clients, which led to the
following warning and incorrect start/end column locations if using
clients with mixed encodings:
warning: multiple different client offset_encodings detected for
buffer, this is not supported yet
Problem: Currently there is no way of customizing behavior of
`declaration`, `definition`, `typeDefinition`, and `implementation`
methods in `vim.lsp.buf` when LSP server returns `Location`. Instead,
cursor jumps to that location directly.
Solution: Normalize LSP response to be `Location[]` for those four cases.
Fixes a regression from 5e5f5174e3
Until that commit we had a logic like this:
`local prefix = startbyte and line:sub(startbyte + 1) or line_to_cursor:sub(word_boundary)`
The commit changed the logic and no longer cut off the line at the cursor, resulting in a prefix that included trailing characters
Fixes https://github.com/neovim/neovim/issues/25177
I initially wanted to split this into a refactor commit to make it more
testable, but it appears that already accidentally fixed the issue by
normalizing lnum/col to 0-indexing
