feat(api): rename buffer to buf
Problem:
`:help dev-name-common` states that "buf" should be used instead of
"buffer" but there are cases where buffer is mentioned in the lua API.
Solution:
- Rename occurrences of "buffer" to "buf" for consistency with the
documentation.
- Support (but deprecate) "buffer" for backwards compatibility.
Co-authored-by: Jordan <46637683+JordanllHarper@users.noreply.github.com>
Problem:
The current LSP diagnostic implementation can't differ between a pull
diagnostic with no identifier and a set of diagnostics provided via push
diagnostics.
"Anonymous pull providers" are expected by the protocol https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#diagnosticOptions
, depending on how the capability was registered:
- Dynamic registrations have an identifier.
- Static registrations will not.
Solution:
Restore the `is_pull` argument removed in
https://github.com/neovim/neovim/pull/37938, keeping the identifier of
pull diagnostic collections.
(cherry picked from commit 665ebce569)
- Add TODO comments for aggregating diagnostics from all pull namespaces
and for clearing diagnostics when an empty array is received, referencing
the LSP specification.
- Update diagnostics refresh logic to safely access previousResultId,
preventing potential nil errors.
Previously, resultId for diagnostics was keyed only by client_id, which
could cause issues when multiple identifiers are used by the same client.
This change introduces a composite key of client_id and identifier for
client_result_id, ensuring correct tracking of diagnostic results per
identifier. Updates all relevant logic to use the new keying scheme.
Update diagnostic refresh to request diagnostics from all provider
registrations using _provider_foreach. This ensures diagnostics are
fetched from every registered provider during a refresh.
Co-authored-by: ZieMcd <ziemcd@gmail.com>
Introduce _provider_foreach to iterate over all matching provider
capabilities for a given LSP method, handling both static and dynamic
registrations. Update diagnostic logic and tests to use the new
iteration approach, simplifying capability access and improving
consistency across features.
Problem:
In autocmd examples, using "args" as the event-object name is vague and
may be confused with a user-command.
Solution:
Use "ev" as the conventional event-object name.
Problem:
Regression from b99cdd0:
Pull diagnostics (from `textDocument/diagnostic`) and push diagnostics
(from `textDocument/publishDiagnostics`) use the same namespace, which
is a problem when using language servers that publish two different sets
of diagnostics on push vs pull, like rust-analyzer (see
https://github.com/rust-lang/rust-analyzer/issues/18709#issuecomment-2551394047).
Solution:
Rename `is_pull` to `pull_id` which accepts a pull namespace instead of
just a boolean.
- Refactor LSP client to use unified provider-based capability lookup for
diagnostics and other features.
- Introduce `_provider_value_get` to abstract capability retrieval,
supporting both static and dynamic registrations.
- Update diagnostic handling and protocol mappings to leverage
provider-centric logic.
Problem:
Some LSP method handlers were making requests without specifying a
bufnr, defaulting to 0 (current). This works in most cases but
fails when client attaches to background buffers, causing
assertions in handlers to fail.
Solution:
Ensure bufnr is passed to Client.request for buffer-local methods.
**Problem:** For unchanged document diagnostic reports, the `resultId`
is ignored completely, even though it should still be saved for the
request (in fact, the spec marks it as mandatory for unchanged reports,
so it should be extra important).
**Solution:** Always store the `resultId`.
This commit allows users to jump to the location specified in a
diagnostic's `relatedInformation`, using `gf` from within the
`open_float` window. The cursor need only be on line that displays the
related info.
Problem:
`vim.diagnostic.set()` doesn't actually accept a list of
`vim.Diagnostic` as internally `vim.diagnostic.set()` normalizes the
diagnostics and this normalization is assumed throughout the module.
Solution:
- Add a new type `vim.Diagnostic.Set` which is the input to `vim.diagnostic.set()`
- `col` is now an optional field and defaults to `0` to be consistent
with `vim.diagnostic.match()`.
- Change `table.insert(t, x)` to `table[#table + 1] = x` for improved
type checking.
**Problem:** For multiline diagnostics, the end column was improperly
calculated by checking the byte index of the character position on the
*start* line.
**Solution:** Calculate the byte index for end_col using the *end* line.
Problem:
Users of the Roslyn (C#) LSP have encountered significant delays when
retrieving pull diagnostics in large documents while using Neovim. For
instance, diagnostics in a 2000-line .cs file can take over 20 seconds
to display after edits in Neovim, whereas in VS Code, diagnostics for
the same file are displayed almost instantly.
As [mparq noted](https://github.com/seblj/roslyn.nvim/issues/93#issuecomment-2508940330)
in https://github.com/seblj/roslyn.nvim/issues/93, VS Code leverages
additional parameters specified in the [LSP documentation for
textDocument/diagnostic](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#documentDiagnosticParams),
specifically:
- previousResultId
- identifier
Solution:
When requesting diagnostics, Neovim should include the
`previousResultId` and `identifier` parameters as part of the request.
These parameters enable the server to utilize caching and return
incremental results.
Support for maintaining state is already present in the
[textDocument/semanticTokens implementation](8f84167c30/runtime/lua/vim/lsp/semantic_tokens.lua (L289)).
A similar mechanism can be implemented in `textDocument/diagnostic` handler.
Problem:
LSP spec uses the term "position encoding" where we say "offset encoding".
Solution:
- Rename it everywhere except `vim.lsp.Client.offset_encoding` (which would be breaking).
- Mention "position encoding" in the documentation for `vim.lsp.Client.offset_encoding`.
- Partition the handlers in vim.lsp.handlers as:
- client to server response handlers (RCS)
- server to client request handlers (RSC)
- server to client notification handlers (NSC)
Note use string indexes instead of protocol.methods for improved
typing in LuaLS (tip: use hover on RCS, RSC or NSC).
* deprecate old signatures
* move to new str_byteindex/str_utfindex signature
* use single-underscore name (double-underscore is reserved for Lua itself)
`buf.code_action` always included diagnostics on a given line from all
clients. Servers should only receive diagnostics they published, and in
the exact same format they sent it.
Should fix https://github.com/neovim/neovim/issues/29500