Closes https://github.com/neovim/neovim/issues/13647
This allows customizing the priority of the highlights.
* Add default priority of 50
* Use priority of 200 for highlight on yank
* use priority of 40 for highlight references (LSP)
Function arguments that expect a list should explicitly use tbl_islist
rather than just checking for a table. This helps catch some simple
errors where a single table item is passed as an argument, which passes
validation (since it's a table), but causes other errors later on.
The overwhelming majority of use cases for `open_float` are to view
diagnostics from the current buffer in a floating window. Thus, most use
cases will just `0` or `nil` as the first argument, which makes the
argument effectively useless and wasteful.
In the cause of optimizing for the primary use case, make the `bufnr`
parameter an optional parameter in the options table. This still allows
using an alternative buffer for those that wish to do so, but makes the
"primary" use case much easier.
The old signature is preserved for backward compatibility, though it can
likely be fully deprecated at some point.
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.
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".
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 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
