| Age | Commit message (Collapse) | Author | Files |
|---|
|
|
|
|
|
Extract the diagnostic implementation from
runtime/lua/vim/diagnostic.lua into focused internal modules covering
config, display, float rendering, jump/list helpers, namespace and
storage management, severity/shared utilities, and statusline support.
Move the builtin handlers into runtime/lua/vim/diagnostic/handlers/ and
keep runtime/lua/vim/diagnostic.lua as the public facade that lazily
dispatches to the split modules. This preserves the external
vim.diagnostic API while making the implementation easier to navigate
and reason about.
AI-assisted: Codex
|
|
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: Justin M. Keyes <justinkz@gmail.com>
|
|
Problem: Multi-line diagnostics always render virtual lines below lnum.
Solution: Use end_lnum when placing the virt_lines extmark.
|
|
The `buffer` option remains functional but is now undocumented.
Providing both will raise an error. Since providing `buf` was disallowed
before, there is no code that will break due to using `buffer` alongside
`buf`.
|
|
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.
|
|
refactor(lua): add integer coercion helpers
Add vim._tointeger() and vim._ensure_integer(), including optional base
support, and switch integer-only tonumber()/assert call sites in the Lua
runtime to use them.
This also cleans up related integer parsing in LSP, health, loader, URI,
tohtml, and Treesitter code.
supported by AI
|
|
Problem:
If a server is slow with catching up, there can be stale diagnostics
for deleted lines. Then if a user uses `jump` it can error like:
E5108: Lua: ...runtime/lua/vim/diagnostic.lua:670: attempt to index a nil value
stack traceback:
...runtime/lua/vim/diagnostic.lua:670: in function 'get_logical_pos'
...runtime/lua/vim/diagnostic.lua:687: in function 'diagnostic_lines'
...runtime/lua/vim/diagnostic.lua:1122: in function 'next_diagnostic'
...runtime/lua/vim/diagnostic.lua:1665: in function 'jump'
Solution:
Fallback to diagnostic location. That's better than the failure.
|
|
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:
During diagnostic position adjustment we may go out of bounds
when trying to get line's length. But it's not clear what kind of
input triggers that.
Solution:
Assert and print relevant input values.
|
|
Problem
LSP Related Information line and column numbers are 0-based. Displaying
them this way can confuse the user, since vim line/col numbers are
typically displayed 1-based.
Solution
Display the line and column numbers as 1-based.
|
|
Problem: The function get_logical_pos did not account for the possibility that a diagnostic might not have an associated extmark, leading to potential errors or incorrect behavior.
Solution: Add a check for diagnostic._extmark_id and return the logical positions directly if it does not exist.
|
|
Problem: random order for same-severity diagnostics, severity_sort reversed.
Solution: add stable comparison with _extmark_id tiebreaker.
|
|
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`.
|
|
Applies the appropriate `DiagnosticSign*` highlight to each group,
resetting the highlights at the end of the expression.
|
|
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
|
|
highlights #36590
Problem: unnecessary and deprecated diagnostics use their own highlight
groups (`DiagnosticUnnecessary` and `DiagnosticDeprecated`) which
override the typical severity-based highlight groups (like
`DiagnosticUnderlineWarn`).
This can be misleading, since diagnostics about unused variables which
are warnings or errors, are shown like comments, since then only the
`DiagnosticUnnecessary` highlight group is used. Users do not see the
more eye-catching red/yellow highlight.
Solution: Instead of overriding the highlight group to
`DiagnosticUnnecessary` or `DiagnosticDeprecated`, set them in addition
to the normal severity-based highlights.
|
|
Fixes #35884
Problem: Since `once_buf_loaded` might call a callback passed to it at a
later point (which is it's reason to exist) that callback might end up
referring to stale diagnostics in a handler's `show` function. For
example, if we first call `vim.diagnostic.set` for an unloaded buffer,
then call `vim.diagnostic.reset` and only then load the buffer, we might
still see diagnostics from `vim.diagnostic.set` call, which are stale at
this point.
Solution: only keep one autocommand from the most reset `show` call and
delete it when `hide` is called.
|
|
Problem:
Diagnostics set on unloaded buffers are not shown when the buffer loads.
Solution:
Use `once_buf_loaded()` to show the diagnostics on BufRead is the buffer
is not yet loaded.
|
|
Type checkers complain if we pass a list of strings, but this should be allowed.
|
|
|
|
Problem: `vim.diagnostic.get_prev()` / `vim.diagnostic.get_next()` use
logical diagnostic positions and consider extmark validity.
`vim.diagnostic.get()` only uses original positions and doesn't care
about extmark validity. This results in inconsistency between these
APIs.
Solution: use original positions in `vim.diagnostic.get_prev()` and
`vim.diagnostic.get_next()` and don't consider extmark validity to match
previous behavior, which is consistent with `vim.diagnostic.get`.
|
|
fix #35116
Co-authored-by: Eisuke Kawashima <e-kwsm@users.noreply.github.com>
|
|
fixes #35116
|
|
Problem:
Not easy to get a status string for diagnostics.
Solution:
- Add vim.diagnostic.status().
- Add it to the default 'statusline'.
|
|
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`).
|
|
Use uppercase to check severity
Mark quickfix items as valid when converting from diagnostics
Support nr/code attribute between formats
|
|
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.
|
|
|
|
|
|
|
|
Type fixes caught by emmylua
|
|
|
|
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.
|
|
Fixes #34013
Problem:
when diagnostic is set right after EOL, underline handler looks
inconsistent compared to other handlers, visually underline is shown
starting from the next line. On top of that it's also inconsistent with
open_float and jump.
Solution:
clamp starting column position in underline handler to be right before
EOL to make it visible and consistent with other handlers, open_float
and jump.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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: `severity` field is recognized by
`vim.diagnostic.Opts.VirtualLines`, but it is not explicitly
documented.
Solution: document it.
|
