summaryrefslogtreecommitdiffstatshomepage
path: root/runtime/lua/vim/lsp/_meta/protocol.lua
AgeCommit message (Collapse)AuthorFiles
2026-02-03feat(lsp): support range + full semantic token requests #37611jdrouhard1
From the LSP Spec: > There are two uses cases where it can be beneficial to only compute > semantic tokens for a visible range: > > - for faster rendering of the tokens in the user interface when a user > opens a file. In this use case, servers should also implement the > textDocument/semanticTokens/full request as well to allow for flicker > free scrolling and semantic coloring of a minimap. > - if computing semantic tokens for a full document is too expensive, > servers can only provide a range call. In this case, the client might > not render a minimap correctly or might even decide to not show any > semantic tokens at all. This commit unifies the usage of range and full/delta requests as recommended by the LSP spec and aligns neovim with the way other LSP clients use these request types for semantic tokens. When a server supports range requests, neovim will simultaneously send a range request and a full/delta request when first opening a file, and will continue to issue range requests until a full response is processed. At that point, range requests cease and full (or delta) requests are used going forward. The range request should allow servers to return a result faster for quicker highlighting of the file while it works on the potentially more expensive full result. If a server decides the full result is too expensive, it can just error out that request, and neovim will continue to use range requests. This commit also fixes and cleans up some other things: - gen_lsp: registrationMethod or registrationOptions imply dynamic registration support - move autocmd creation/deletion to on_attach/on_detach - debounce requests due to server refresh notifications - fix off by one issue in tokens_to_ranges() iteration
2025-10-07fix(lsp): use LSP method type in more places (#36069)Maria Solano1
2025-08-03fix(lsp): decode 'null' in server responses as vim.NIL #34849skewb1k1
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.
2025-04-17refactor(lsp): gen_lspLewis Russell1
- Simplify usage: - Instead of `nvim -l src/gen/gen_lsp.lua gen` now just run `./src/gen/gen_lsp.lua` - Removed `--methods` and `--capabilities` options. - Improved rendering code in various areas.
2025-04-17feat(lsp): use stricter types for methodsLewis Russell1
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.
2025-02-17feat(lsp): update LSP typesMaria José Solano1
2024-08-20docs(lsp): annotate with `vim.lsp.protocol.Methods` enum #29521Ricardo Casía1
Added the enum type annotation `vim.lsp.protocol.Methods` to provide some intellisense support.
2024-05-31refactor(lsp): use tuple syntax in generated protocol types (#29110)Ilia Choly1
2024-05-14feat(lsp): update LSP protocol 3.18 typings to date (#28730)Jongwook Choi1
Make the LSP protocol typings up-to-date with LSP protocol (upcoming) version 3.18, before and in preparation for the Nvim 0.10.0 release.
2024-02-21fix(lsp): add parentheses to generated union array types (#27560)Maria José Solano1
2024-01-20fix(lsp): clean up duplicate and unused meta type annotationsJongwook Choi1
2023-12-27fix(gen_lsp.lua): improve type name, and fix wrong type inheritanceJongwook Choi1
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.
2023-12-27docs(gen_lsp.lua): re-generate vim.lsp._meta.protocol type annotationsJongwook Choi1
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)
2023-12-11feat(gen_lsp.lua): validate CLI args #26514Jongwook Choi1
- 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.
2023-08-09fix(lua): improve annotations for stricter luals diagnostics (#24609)Christian Clason1
Problem: luals returns stricter diagnostics with bundled luarc.json Solution: Improve some function and type annotations: * use recognized uv.* types * disable diagnostic for global `vim` in shared.lua * docs: don't start comment lines with taglink (otherwise LuaLS will interpret it as a type) * add type alias for lpeg pattern * fix return annotation for `vim.secure.trust` * rename local Range object in vim.version (shadows `Range` in vim.treesitter) * fix some "missing fields" warnings * add missing required fields for test functions in eval.lua * rename lsp meta files for consistency