04bfd20bb introduced a subtle bug where using 0 as the buffer number in
the diagnostic cache resets the cache for the current buffer. This
happens because we were not checking to see if the _resolved_ buffer
number already existed in the cache; rather, when the __index metamethod
was called we assumed the index did not exist so we set its value to an
empty table. The fix for this is to check `rawget()` for the resolved
buffer number to see if the index already exists.
However, the reason this bug was introduced in the first place was
because we are simply being too clever by allowing a 0 buffer number as
the index which is automatically resolved to a real buffer number.
In the interest of minimizing metatable magic, remove this "feature" by
requiring the buffer number index to always be a valid buffer. This
ensures that the __index metamethod is only ever called for non-existing
buffers (which is what we wanted originally) as well as reduces some of
the cognitive overhead for understanding how the diagnostic cache works.
The tradeoff is that all public API functions must now resolve 0 buffer
numbers to the current buffer number.
Errors were being caused by invalid buffers being kept around in
diagnostic_cache, so add a metatable to diagnostic_cache which attaches
to new buffers in the cache, removing them after they are invalidated.
Closes#16391.
Co-authored-by: Gregory Anders <8965202+gpanders@users.noreply.github.com>
The current 'clamp_line_numbers' implementation modifies diagnostics in
place, which can have adverse downstream side effects. Before clamping
line numbers, make a copy of the diagnostic. This commit also merges the
'clamp_line_numbers' method into a new 'get_diagnostics' local function
which also implements the more general "get" method. The public
'vim.diagnostic.get()' API now just uses this function (without
clamping). This has the added benefit that other internal API functions
that need to use get() no longer have to go through vim.validate.
Finally, reorganize the source code a bit by grouping all of the data
structures together near the top of the file.
If the quickfixlist item doesn't contain a column it is reported as 0.
Rather than using a nil value in such a case (which breaks diagnostics
elsewhere), just keep the 0 value.
Make the bufnr argument have similar semantics across API functions;
namely, a nil value means "all buffers" while 0 means "current buffer".
This increases the flexibility of the API by allowing functions such as
enable() and disable() to apply globally or per-namespace, rather than
only on a specific buffer.
Also fix a few other small bugs regarding saving and restoring extmarks.
In particular, now that the virtual text and underline handlers have
their own dedicated namespaces, they should be responsible for saving
and restoring their own extmarks. Also fix the wrong argument ordering
in the call to `clear_diagnostic_cache` in the `on_detach` callback.
Rather than treating virtual_text, signs, and underline specially,
introduce the concept of generic "handlers", of which those three are
simply the defaults bundled with Nvim. Handlers are called in
`vim.diagnostic.show()` and `vim.diagnostic.hide()` and are used to
handle how diagnostics are displayed.
'show_line_diagnostics()' and 'show_position_diagnostics()' are
almost identical; they differ only in the fact that the latter also
accepts a column to form a full position, rather than just a line. This
is not enough to justify two separate interfaces for this common
functionality.
Renaming this to simply 'show_diagnostics()' is one step forward, but
that is also not a good name as the '_diagnostics()' suffix is
redundant. However, we cannot name it simply 'show()' since that
function already exists with entirely different semantics.
Instead, combine these two into a single 'open_float()' function that
handles all of the cases of showing diagnostics in a floating window.
Also add a "float" key to 'vim.diagnostic.config()' to provide global
values of configuration options that can be overridden ephemerally.
This makes the float API consistent with the rest of the diagnostic API.
BREAKING CHANGE
When using `true` as the value of a configuration option, the option is
configured to use default values. For example, if a user configures
virtual text to include the source globally (using
vim.diagnostic.config) and a specific namespace or producer configures
virtual text with `virt_text = true`, the user's global configuration is
overriden.
Instead, interpret a value of `true` to mean "use existing settings if
defined, otherwise use defaults".
Users can pass string values for severities that match with the enum
names (e.g. "Warn" or "Info") which are converted to the corresponding
numerical value in `to_severity`. Invalid strings were simply left
as-is, which caused confusing errors later on. Instead, report an
invalid severity string right up front to make the problem clear.
Always make calls to `vim.diagnostic.set` call `vim.diagnostic.show`.
This creates an easier to reason about code path and is also less
surprising when users wish to override override `vim.diagnostic.show`
with custom behavior and `vim.diagnostic.set` is called with empty
diagnostics.
Functionally, the end result is the same: when `show` is called with an
empty diagnostics list, it just calls `hide` and then returns, which is
exactly what `reset` does right now.
Many vim.diagnostic functions expect the user to pass in a namespace id.
This PR allows the user to list active diagnostic namespaces:
```lua
:lua print(vim.inspect(vim.diagnostic.get_namespaces()))
{
[7] = {
name = "vim.lsp.client-1",
opts = {},
sign_group = "vim.diagnostic.vim.lsp.client-1"
}
}
```
Rather than relying on the order in which signs are placed to dictate
the order in which they are displayed, explicitly set the priority of
the sign according to the severity of the diagnostic and the value of
severity_sort. If severity_sort is false or unset then all signs use the
same priority.
diagnostic_lines() returns a table, so make the early exit condition an
empty table rather than 'nil'. This way, functions that use the input
from diagnostic_lines don't have to do a bunch of defensive nil checking
and can always assume they're operating on a table.
This function isn't compatible with including diagnostic sources when
"source" is "if_many" since it only has access to diagnostics for a
single line. Rather than having an inconsistent or incomplete interface,
make this function private. It is still exported as part of the module
for backward compatibility with vim.lsp.diagnostics, but it can
eventually be made into a local function.
Some parts of LSP need to use cached diagnostics as sent from the LSP
server unmodified. Rather than fixing invalid line numbers when
diagnostics are first set, fix them when they are displayed to the user
(e.g. in show() or one of the get_next/get_prev family of functions).
* feat(diagnostic): add vim.diagnostic.match()
Provide vim.diagnostic.match() to generate a diagnostic from a string and
a Lua pattern.
* feat(diagnostic): add tolist() and fromlist()
When vim.diagnostic.config() is called, the decorations for diagnostics
are re-displayed to use the new configuration. This should only be done
for loaded buffers.
When severity_sort is true, higher severities should be displayed before
lower severities (e.g. ERROR is displayed over WARN).
Also improved the test case for this.
This generalizes diagnostic handling outside of just the scope of LSP.
LSP clients are now a specific case of a diagnostic producer, but the
diagnostic subsystem is decoupled from the LSP subsystem (or will be,
eventually).
More discussion at [1].
[1]: https://github.com/neovim/neovim/pull/15585
