Problem:
`diagnostic.status` only follows the `config.status.format` setting to determine how to display diagnostic signs. However, `signs` can actually also be configured via `config.signs.text`.
Solution:
If the user has set symbols via `config.status.format`, let that determine the content of `signs`; otherwise, use `config.signs.text` for display.
TODO: drop support `type(config.status.format) == 'table'`; users should just configure `config.signs.text` directly.
Problem: Using severity names (like "ERROR", "WARN") in functions like
`vim.diganostic.get()` and `vim.diagnostic.config()` is allowed and
tested for many years now. But documentation about it can be clearer.
Solution: Explicitly mention that severity names are allowed in some
situations. Ideally, it would also require updating typing for
`vim.diagnostic.SeverityFilter`, but that looks problematic to do
robustly.
Problem:
The `float` field of vim.diagnostic.config can be a function,
but diagnostic.open_float() does not handle it correctly.
Solution:
Add handling for it in open_float().
Problem: Statusline component of diagnostics allows only the default
format "sign:count".
Solution: Extend vim.diagnostic.Opts.Status to allow a custom signs
or formatting function that provides the status presentation.
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: currently in the example a new diagnostic namespace is created
for showing it manually with a custom config. Because of a separate
namespace, when the original diagnostic source sets diagnostics again,
it will not affect the diagnostic shown in that new namespace and the
user would need to implement the logic for hiding it themselves,
separately as well.
Solution: instead of creating a new namespace, reuse the original
diagnostic's namespace, so once the source sets diagnostics again, it's
removed and hidden automatically without user having to do anything
extra for that.
Problem:
`vim.diagnostic.fromqflist` ignores lines that are `item.valid == 0` (see
`getqflist`). Many qflists have messages that span multiple lines, which look
like this:
collection/src/Modelling/CdOd/Central.hs|496 col 80| error: [GHC-83865]
|| • Couldn't match expected type: InstanceWithForm
|| (FilePath
|| -> SelectValidCdInstWithForm
...
calling `vim.diagnostic.fromqflist(vim.fn.getqflist)` gets a diagnostic message
like this:
error: [GHC-83865]
only the first line is kept, but often, the remaing lines are useful as well.
Solution:
Introduce `merge_lines` option, which "squashes" lines from invalid qflist items
into the error message of the previous valid item, so that we get this
diagnostic message instead:
error: [GHC-83865]
• Couldn't match expected type: InstanceWithForm
(FilePath
-> SelectValidCdInstWithForm
Problem:
`diagnostic.status()` is configured via `config.signs`, but users may
want diagnostics only in statusline, not in the gutter (signs).
Solution:
Add `config.status`.
Problem: the opts table also is param of util.open_floating_preview,
vim.diagnostic.Opts.Float missing some fields of open_floating_preview.
Solution: diagnostic.Opts.Float extend util.open_floating_preview.Opts
Fix#29267
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.
- Add missing diagnostics virtual lines hl groups.
- Fix LSP dynamic registration example; curbuf may not actually be attached to
the client, and it may be attached to many such buffers.
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.
Problem: Right aligned virtual text can cover up buffer text if virtual
text is too long
Solution: An additional option for `virt_text_pos` called
`eol_right_align` has been added to truncate virtual text if it would
have otherwise covered up buffer text. This ensures the virtual text
extends no further left than EOL.
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.
BREAKING CHANGE: This changes the list of diagnostics that are passed to
a diagnostic handler. If a handler is already filtering by severity
itself then this won't break anything, since the handler's filtering
will become a no-op. But handlers which depend on receiving the full
list of diagnostics may break.
Note that diagnostics are only filtered if the handler's configuration
has the `severity` option set. If `severity` is not set, the handler
still receives the full list of diagnostics.
feat(diagnostics)!: sort underline with severity_sort
BREAKING CHANGE: underline will be applied with a higher value than `vim.hl.priorities.diagnostics`
An implication of this current approach is that `NVIM_API_LEVEL` should be
bumped when a new Lua function is added.
TODO(future): add a lint check which requires `@since` on all new functions.
ref #25416
Problem: the code and docs for vim.diagnostic.JumpOpts.float send mixed
signals about what the default should be. When the option is first set,
in the global_diagnostic_options table, the comment clearly says that
the default is false. Later in the code, in goto_diagnostic, there's
a line that sets the default to true if no default is present. Finally,
the docs say that the default is true.
Solution: Change the docs to reflect the new default of false and fix
the goto_diagnostic function.
