Problem:
diagnostic extmark used for positioning continues to exist after
deleting a range containing it, so it's possible to jump to a
next/previous diagnositc, which isn't visible in any way, including not
being shown via `open_float`.
Solution:
enable `invalidate` flag when setting an extmark to be able to filter
out diagnostics based on `invalid` flag when looking for next/previous
diagnostic to jump to.
Problem:
Diagnostic positions are not being updated after text changes, which
means `vim.diagnostic.open_float` and `vim.diagnostic.jump` will work
with outdated positions when text is changed until diagnostics are
updated again (if ever).
Solution:
Create extmarks in `vim.diagnostic.set` and use their positions for
`vim.diagnostic.open_float` and `next_diagnostic` (used by
`vim.diagnostic.jump`, `vim.diagnostic.get_next` and
`vim.diagnostic.get_prev`).
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:
virtual_text diagnostics are great when skimming a file, and
virtual_lines are great when "zooming in" on a particular problem.
Having both enabled results in duplicate diagnostics on-screen.
Solution:
This PR expands the behavior of `current_line` for virtual_text and
virtual_lines by making `virtual_text.current_line = false` distinct
from `nil`. If you set:
vim.diagnostic.config({
virtual_text = { current_line = false },
virtual_lines = { current_line = true },
})
With this configuration, virtual_text will be used to display
diagnostics until the cursor reaches the same line, at which point they
will be hidden and virtual_lines will take its place.
When multiple diagnostics appear on a single line, the virtual lines for
all diagnostics except the first were rendered with progressively fewer
columns.
Making this opt-out (on by default) was the wrong choice from the
beginning. It is too visually noisy to be enabled by default.
BREAKING CHANGE: Users must opt-in to the diagnostic virtual text
handler by adding
vim.diagnostic.config({ virtual_text = true })
to their config.
Problem:
Regression from de794f2d24: `vim.diagnostic.setqflist{open=true}` attempts to
open the location list instead of the diagnostics quickfix list if it didn't
exist before. This is because we are using `qf_id` to decide which to open, but
`qf_id=nil` when there is no existing diagnostics quickfix list with a given
title ("Diagnostics" by default).
Solution:
- Revert to using `loclist` to decide which to open.
- Add tests.
feat(diagnostics)!: sort underline with severity_sort
BREAKING CHANGE: underline will be applied with a higher value than `vim.hl.priorities.diagnostics`
Problem:
Tests have lots of exec_lua calls which input blocks of code
provided as unformatted strings.
Solution:
Teach exec_lua how to handle functions.
Deprecate vim.diagnostic.goto_prev() and vim.diagnostic.goto_next() in
favor of a unified vim.diagnostic.jump() interface.
We cannot name the function "goto()" because some of our tooling
(luacheck and stylua) fail to parse it, presumably because "goto" is a
keyword in newer versions of Lua.
vim.diagnostic.jump() also allows moving to a specific diagnostic and
moving by multiple diagnostics at a time (useful for creating mappings
that use v:count).
Follow-up to #28490
Problem:
The new behaviour of goto_next/prev() of navigating to the next highest
severity doesn't work well when diagnostic providers have different
interpretations of severities. E.g. the user may be blocked from
navigating to a useful LSP warning, due to some linter error.
Solution:
The behaviour of next highest severity is now a hidden option
`_highest = true`. We can revisit how to integrate this behaviour
during the 0.11 cycle.
Problem: when line is blank link then there will got an invalid column number in math.min compare.
Solution: make sure the min column number is 0 not an illegal number.
Specifically, functions that are run in the context of the test runner
are put in module `test/testutil.lua` while the functions that are run
in the context of the test session are put in
`test/functional/testnvim.lua`.
Closes https://github.com/neovim/neovim/issues/27004.
Problem:
We need to establish a pattern for `enable()`.
Solution:
- First `enable()` parameter is always `enable:boolean`.
- Update `vim.diagnostic.enable()`
- Update `vim.lsp.inlay_hint.enable()`.
- It was not released yet, so no deprecation is needed. But to help
HEAD users, it will show an informative error.
- vim.deprecate():
- Improve message when the "removal version" is a *current or older* version.
Problem:
vim.diagnostic.enable() does not match the signature of vim.lsp.inlay_hint.enable()
Solution:
- Change the signature so that the first 2 args are (bufnr, enable).
- Introduce a 3rd `opts` arg.
- Currently it only supports `opts.ns_id`.
Problem:
`vim.diagnostic.is_disabled` and `vim.diagnostic.disable` are unnecessary
and inconsistent with the "toggle" pattern (established starting with
`vim.lsp.inlay_hint`, see https://github.com/neovim/neovim/pull/25512#pullrequestreview-1676750276
As a reminder, the rationale is:
- we always need `enable()`
- we always end up needing `is_enabled()`
- "toggle" can be achieved via `enable(not is_enabled())`
- therefore,
- `toggle()` and `disable()` are redundant
- `is_disabled()` is a needless inconsistency
Solution:
- Introduce `vim.diagnostic.is_enabled`, and `vim.diagnostic.enable(…, enable:boolean)`
- Note: Future improvement would be to add an `enable()` overload `enable(enable:boolean, opts: table)`.
- Deprecate `vim.diagnostic.is_disabled`, `vim.diagnostic.disable`
`exec_lua` makes code slighly harder to read, so it's beneficial to
remove it in cases where it's possible or convenient.
Not all `exec_lua` calls should be removed even if the test passes as it
changes the semantics of the test even if it happens to pass.
From https://github.com/neovim/neovim/pull/28155#discussion_r1548185779:
"Note for tests like this, which fundamentally are about conversion, you
end up changing what conversion you are testing. Even if the result
happens to be same (as they often are, as we like the rules to be
consistent if possible), you are now testing the RPC conversion rules
instead of the vim script to in-process lua conversion rules."
From https://github.com/neovim/neovim/pull/28155#discussion_r1548190152:
"A test like this specifies that the cursor is valid immediately and not
after a separate cycle of normal (or an other input-processing) mode."
feat(diagnostic): add `vim.diagnostic.count()`
Problem: Getting diagnostic count based on the output of
`vim.diagnostic.get()` might become costly as number of diagnostic
entries grows. This is because it returns a copy of diagnostic cache
entries (so as to not allow users to change them in place).
Getting information about diagnostic count is frequently used in
statusline, so it is important to be as fast as reasonbly possible.
Solution: Add `vim.diagnostic.count()` which computes severity
counts without making copies.
Diagnostic signs should now be configured with vim.diagnostic.config(),
but "legacy" sign definitions should go through the standard deprecation
process to minimize the impact from breaking changes.
The prefix option of the diagnostic virtual text can be a function,
but previously it was only a function of diagnostic.
This function should also have additional parameters index and total,
more consistently and similarily as in the prefix function for
`vim.diagnostic.open_float()`.
These additional parameters will be useful when there are too many
number of diagnostics in a single line.
