kevin/neovim
1
Fork 0
mirror of https://github.com/neovim/neovim.git synced 2024-12-29 14:41:06 -07:00
Code Issues Packages Projects Releases Wiki Activity
cd1b14f027
neovim/runtime/doc/diagnostic.txt

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

794 lines
35 KiB
Plaintext
Raw Normal View History

refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
*diagnostic.txt* Diagnostics
NVIM REFERENCE MANUAL
Diagnostic framework *vim.diagnostic*
Nvim provides a framework for displaying errors or warnings from external
tools, otherwise known as "diagnostics". These diagnostics can come from a
variety of sources, such as linters or LSP servers. The diagnostic framework
is an extension to existing error handling functionality such as the
|quickfix| list.
Type |gO| to see the table of contents.
==============================================================================
QUICKSTART *diagnostic-quickstart*
Anything that reports diagnostics is referred to below as a "diagnostic
producer". Diagnostic producers need only follow a few simple steps to
report diagnostics:
1. Create a namespace |nvim_create_namespace()|. Note that the namespace must
have a name. Anonymous namespaces WILL NOT WORK.
2. (Optional) Configure options for the diagnostic namespace
|vim.diagnostic.config()|.
3. Generate diagnostics.
4. Set the diagnostics for the buffer |vim.diagnostic.set()|.
5. Repeat from step 3.
Generally speaking, the API is split between functions meant to be used by
diagnostic producers and those meant for diagnostic consumers (i.e. end users
who want to read and view the diagnostics for a buffer). The APIs for
producers require a {namespace} as their first argument, while those for
consumers generally do not require a namespace (though often one may be
optionally supplied). A good rule of thumb is that if a method is meant to
modify the diagnostics for a buffer (e.g. |vim.diagnostic.set()|) then it
requires a namespace.
*diagnostic-structure*
feat(diagnostic): add "code" to the diagnostic structure (#17510)
2022-03-02 18:42:27 -07:00
A diagnostic is a Lua table with the following keys. Required keys are
docs: fix more treesitter parsing errors
2023-02-21 09:39:29 -07:00
indicated with (+):
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
fix(docs): add bufnr and user_data to diagnostic-structure (#16619)
2021-12-11 08:59:16 -07:00
bufnr: Buffer number
docs: fix more treesitter parsing errors
2023-02-21 09:39:29 -07:00
lnum(+): The starting line of the diagnostic
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
end_lnum: The final line of the diagnostic
docs: fix more treesitter parsing errors
2023-02-21 09:39:29 -07:00
col(+): The starting column of the diagnostic
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
end_col: The final column of the diagnostic
severity: The severity of the diagnostic |vim.diagnostic.severity|
docs: fix more treesitter parsing errors
2023-02-21 09:39:29 -07:00
message(+): The diagnostic text
feat(diagnostic): add option to include diagnostic source Add an option to virtual text display and floating window previews to include diagnostic source in the diagnostic message.
2021-09-18 14:00:32 -07:00
source: The source of the diagnostic
feat(diagnostic): add "code" to the diagnostic structure (#17510)
2022-03-02 18:42:27 -07:00
code: The diagnostic code
fix(docs): add bufnr and user_data to diagnostic-structure (#16619)
2021-12-11 08:59:16 -07:00
user_data: Arbitrary data plugins or users can add
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
Diagnostics use the same indexing as the rest of the Nvim API (i.e. 0-based
rows and columns). |api-indexing|
*vim.diagnostic.severity* *diagnostic-severity*
The "severity" key in a diagnostic is one of the values defined in
`vim.diagnostic.severity`:
vim.diagnostic.severity.ERROR
vim.diagnostic.severity.WARN
vim.diagnostic.severity.INFO
vim.diagnostic.severity.HINT
Functions that take a severity as an optional parameter (e.g.
feat(diagnostic): filter diagnostics by specific severities (#24736) Allow users to filter diagnostics by specifying severities
2023-08-16 06:49:14 -07:00
|vim.diagnostic.get()|) accept one of three forms:
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
docs: add language annotation to Nvim manual
2022-11-22 10:41:00 -07:00
1. A single |vim.diagnostic.severity| value: >lua
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
vim.diagnostic.get(0, { severity = vim.diagnostic.severity.WARN })
docs: add language annotation to Nvim manual
2022-11-22 10:41:00 -07:00
2. A table with a "min" or "max" key (or both): >lua
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
chore: fix typos (#17331) Co-authored-by: Hongyi Lyu <hongyi.lyu95@gmail.com> Co-authored-by: Gregory Anders <greg@gpanders.com> Co-authored-by: notomo <notomo.motono@gmail.com> Co-authored-by: zeertzjq <zeertzjq@outlook.com>
2022-03-09 23:34:55 -07:00
vim.diagnostic.get(0, { severity = { min = vim.diagnostic.severity.WARN } })
feat(diagnostic): filter diagnostics by specific severities (#24736) Allow users to filter diagnostics by specifying severities
2023-08-16 06:49:14 -07:00
<
This form allows users to specify a range of severities.
3. A list-like table: >lua
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
feat(diagnostic): filter diagnostics by specific severities (#24736) Allow users to filter diagnostics by specifying severities
2023-08-16 06:49:14 -07:00
vim.diagnostic.get(0, { severity = {
vim.diagnostic.severity.WARN,
vim.diagnostic.severity.INFO,
} })
<
This form allows users to filter for specific severities
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
refactor(diagnostic): make display handlers generic (#16137) 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.
2021-10-29 18:47:34 -07:00
==============================================================================
HANDLERS *diagnostic-handlers*
Diagnostics are shown to the user with |vim.diagnostic.show()|. The display of
diagnostics is managed through handlers. A handler is a table with a "show"
and (optionally) a "hide" function. The "show" function has the signature
>
function(namespace, bufnr, diagnostics, opts)
<
and is responsible for displaying or otherwise handling the given
diagnostics. The "hide" function takes care of "cleaning up" any actions taken
by the "show" function and has the signature
>
function(namespace, bufnr)
<
Handlers can be configured with |vim.diagnostic.config()| and added by
creating a new key in `vim.diagnostic.handlers` (see
|diagnostic-handlers-example|).
The {opts} table passed to a handler is the full set of configuration options
(that is, it is not limited to just the options for the handler itself). The
values in the table are already resolved (i.e. if a user specifies a
function for a config option, the function has already been evaluated).
Nvim provides these handlers by default: "virtual_text", "signs", and
"underline".
*diagnostic-handlers-example*
The example below creates a new handler that notifies the user of diagnostics
docs: add language annotation to Nvim manual
2022-11-22 10:41:00 -07:00
with |vim.notify()|: >lua
refactor(diagnostic): make display handlers generic (#16137) 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.
2021-10-29 18:47:34 -07:00
-- It's good practice to namespace custom handlers to avoid collisions
vim.diagnostic.handlers["my/notify"] = {
show = function(namespace, bufnr, diagnostics, opts)
-- In our example, the opts table has a "log_level" option
local level = opts["my/notify"].log_level
docs: regenerate
2022-08-11 05:25:48 -07:00
refactor(diagnostic): make display handlers generic (#16137) 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.
2021-10-29 18:47:34 -07:00
local name = vim.diagnostic.get_namespace(namespace).name
local msg = string.format("%d diagnostics in buffer %d from %s",
#diagnostics,
bufnr,
name)
vim.notify(msg, level)
end,
}
docs: regenerate
2022-08-11 05:25:48 -07:00
refactor(diagnostic): make display handlers generic (#16137) 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.
2021-10-29 18:47:34 -07:00
-- Users can configure the handler
vim.diagnostic.config({
["my/notify"] = {
log_level = vim.log.levels.INFO
}
})
<
In this example, there is nothing to do when diagnostics are hidden, so we
omit the "hide" function.
Existing handlers can be overridden. For example, use the following to only
docs: add language annotation to Nvim manual
2022-11-22 10:41:00 -07:00
show a sign for the highest severity diagnostic on a given line: >lua
refactor(diagnostic): make display handlers generic (#16137) 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.
2021-10-29 18:47:34 -07:00
-- Create a custom namespace. This will aggregate signs from all other
-- namespaces and only show the one with the highest severity on a
-- given line
local ns = vim.api.nvim_create_namespace("my_namespace")
docs: regenerate
2022-08-11 05:25:48 -07:00
refactor(diagnostic): make display handlers generic (#16137) 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.
2021-10-29 18:47:34 -07:00
-- Get a reference to the original signs handler
local orig_signs_handler = vim.diagnostic.handlers.signs
docs: regenerate
2022-08-11 05:25:48 -07:00
refactor(diagnostic): make display handlers generic (#16137) 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.
2021-10-29 18:47:34 -07:00
-- Override the built-in signs handler
vim.diagnostic.handlers.signs = {
show = function(_, bufnr, _, opts)
-- Get all diagnostics from the whole buffer rather than just the
-- diagnostics passed to the handler
local diagnostics = vim.diagnostic.get(bufnr)
docs: regenerate
2022-08-11 05:25:48 -07:00
refactor(diagnostic): make display handlers generic (#16137) 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.
2021-10-29 18:47:34 -07:00
-- Find the "worst" diagnostic per line
local max_severity_per_line = {}
for _, d in pairs(diagnostics) do
local m = max_severity_per_line[d.lnum]
if not m or d.severity < m.severity then
max_severity_per_line[d.lnum] = d
end
end
docs: regenerate
2022-08-11 05:25:48 -07:00
refactor(diagnostic): make display handlers generic (#16137) 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.
2021-10-29 18:47:34 -07:00
-- Pass the filtered diagnostics (with our custom namespace) to
-- the original handler
local filtered_diagnostics = vim.tbl_values(max_severity_per_line)
orig_signs_handler.show(ns, bufnr, filtered_diagnostics, opts)
end,
hide = function(_, bufnr)
orig_signs_handler.hide(ns, bufnr)
end,
}
<
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
==============================================================================
HIGHLIGHTS *diagnostic-highlights*
All highlights defined for diagnostics begin with `Diagnostic` followed by
the type of highlight (e.g., `Sign`, `Underline`, etc.) and the severity (e.g.
`Error`, `Warn`, etc.)
By default, highlights for signs, floating windows, and virtual text are linked to the
corresponding default highlight. Underline highlights are not linked and use their
own default highlight groups.
For example, the default highlighting for |hl-DiagnosticSignError| is linked
to |hl-DiagnosticError|. To change the default (and therefore the linked
docs: add language annotation to Nvim manual
2022-11-22 10:41:00 -07:00
highlights), use the |:highlight| command: >vim
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
highlight DiagnosticError guifg="BrightRed"
<
*hl-DiagnosticError*
DiagnosticError
Used as the base highlight group.
Other Diagnostic highlights link to this by default (except Underline)
*hl-DiagnosticWarn*
DiagnosticWarn
Used as the base highlight group.
Other Diagnostic highlights link to this by default (except Underline)
*hl-DiagnosticInfo*
DiagnosticInfo
Used as the base highlight group.
Other Diagnostic highlights link to this by default (except Underline)
*hl-DiagnosticHint*
DiagnosticHint
feat(highlight): add DiagnosticOk (and associated) highlight groups (#21286) The existing groups, Error, Hint, Info, Warn cover many use cases, but neglect the occasion where a diagnostic message should communicate a non-informative (not a Hint or Info) event. DiagnosticOk covers this with a generic green colorscheme.
2022-12-28 09:01:40 -07:00
Used as the base highlight group.
Other Diagnostic highlights link to this by default (except Underline)
*hl-DiagnosticOk*
DiagnosticOk
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
Used as the base highlight group.
Other Diagnostic highlights link to this by default (except Underline)
*hl-DiagnosticVirtualTextError*
DiagnosticVirtualTextError
Used for "Error" diagnostic virtual text.
*hl-DiagnosticVirtualTextWarn*
DiagnosticVirtualTextWarn
Used for "Warn" diagnostic virtual text.
*hl-DiagnosticVirtualTextInfo*
DiagnosticVirtualTextInfo
Used for "Info" diagnostic virtual text.
*hl-DiagnosticVirtualTextHint*
DiagnosticVirtualTextHint
Used for "Hint" diagnostic virtual text.
feat(highlight): add DiagnosticOk (and associated) highlight groups (#21286) The existing groups, Error, Hint, Info, Warn cover many use cases, but neglect the occasion where a diagnostic message should communicate a non-informative (not a Hint or Info) event. DiagnosticOk covers this with a generic green colorscheme.
2022-12-28 09:01:40 -07:00
*hl-DiagnosticVirtualTextOk*
DiagnosticVirtualTextOk
Used for "Ok" diagnostic virtual text.
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
*hl-DiagnosticUnderlineError*
DiagnosticUnderlineError
Used to underline "Error" diagnostics.
*hl-DiagnosticUnderlineWarn*
DiagnosticUnderlineWarn
Used to underline "Warn" diagnostics.
*hl-DiagnosticUnderlineInfo*
DiagnosticUnderlineInfo
Used to underline "Info" diagnostics.
*hl-DiagnosticUnderlineHint*
DiagnosticUnderlineHint
Used to underline "Hint" diagnostics.
feat(highlight): add DiagnosticOk (and associated) highlight groups (#21286) The existing groups, Error, Hint, Info, Warn cover many use cases, but neglect the occasion where a diagnostic message should communicate a non-informative (not a Hint or Info) event. DiagnosticOk covers this with a generic green colorscheme.
2022-12-28 09:01:40 -07:00
*hl-DiagnosticUnderlineOk*
DiagnosticUnderlineOk
Used to underline "Ok" diagnostics.
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
*hl-DiagnosticFloatingError*
DiagnosticFloatingError
Used to color "Error" diagnostic messages in diagnostics float.
feat(diagnostic): use `scope = 'line'` by default for `open_float()` (#16456) Closes #16453 Co-authored-by: Cédric Barreteau <cbarrete@users.noreply.github.com>
2021-11-28 09:42:29 -07:00
See |vim.diagnostic.open_float()|
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
*hl-DiagnosticFloatingWarn*
DiagnosticFloatingWarn
Used to color "Warn" diagnostic messages in diagnostics float.
*hl-DiagnosticFloatingInfo*
DiagnosticFloatingInfo
Used to color "Info" diagnostic messages in diagnostics float.
*hl-DiagnosticFloatingHint*
DiagnosticFloatingHint
Used to color "Hint" diagnostic messages in diagnostics float.
feat(highlight): add DiagnosticOk (and associated) highlight groups (#21286) The existing groups, Error, Hint, Info, Warn cover many use cases, but neglect the occasion where a diagnostic message should communicate a non-informative (not a Hint or Info) event. DiagnosticOk covers this with a generic green colorscheme.
2022-12-28 09:01:40 -07:00
*hl-DiagnosticFloatingOk*
DiagnosticFloatingOk
Used to color "Ok" diagnostic messages in diagnostics float.
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
*hl-DiagnosticSignError*
DiagnosticSignError
Used for "Error" signs in sign column.
*hl-DiagnosticSignWarn*
DiagnosticSignWarn
Used for "Warn" signs in sign column.
*hl-DiagnosticSignInfo*
DiagnosticSignInfo
Used for "Info" signs in sign column.
*hl-DiagnosticSignHint*
DiagnosticSignHint
Used for "Hint" signs in sign column.
feat(highlight): add DiagnosticOk (and associated) highlight groups (#21286) The existing groups, Error, Hint, Info, Warn cover many use cases, but neglect the occasion where a diagnostic message should communicate a non-informative (not a Hint or Info) event. DiagnosticOk covers this with a generic green colorscheme.
2022-12-28 09:01:40 -07:00
*hl-DiagnosticSignOk*
DiagnosticSignOk
Used for "Ok" signs in sign column.
docs: add `hl-DiagnosticDeprecated` and `hl-DiagnosticUnnecessary`
2023-04-08 10:19:39 -07:00
*hl-DiagnosticDeprecated*
DiagnosticDeprecated
Used for deprecated or obsolete code.
*hl-DiagnosticUnnecessary*
DiagnosticUnnecessary
Used for unnecessary or unused code.
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
==============================================================================
SIGNS *diagnostic-signs*
Signs are defined for each diagnostic severity. The default text for each sign
is the first letter of the severity name (for example, "E" for ERROR). Signs
docs: add language annotation to Nvim manual
2022-11-22 10:41:00 -07:00
can be customized using the following: >vim
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
sign define DiagnosticSignError text=E texthl=DiagnosticSignError linehl= numhl=
feat(diagnostic): match(), tolist(), fromlist() #15704 * 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()
2021-09-19 15:13:23 -07:00
sign define DiagnosticSignWarn text=W texthl=DiagnosticSignWarn linehl= numhl=
sign define DiagnosticSignInfo text=I texthl=DiagnosticSignInfo linehl= numhl=
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
sign define DiagnosticSignHint text=H texthl=DiagnosticSignHint linehl= numhl=
refactor(diagnostic): use sign priority for severity_sort #15785 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.
2021-09-26 16:02:18 -07:00
When the "severity_sort" option is set (see |vim.diagnostic.config()|) the
priority of each sign depends on the severity of the associated diagnostic.
Otherwise, all signs have the same priority (the value of the "priority"
option in the "signs" table of |vim.diagnostic.config()| or 10 if unset).
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
==============================================================================
EVENTS *diagnostic-events*
feat(diagnostic)!: make DiagnosticChanged a first class autocmd (#16098) This allows users to hook into diagnostic events with finer granularity (e.g. per-buffer or file). BREAKING CHANGE: DiagnosticsChanged and LspDiagnosticsChanged user autocommands are removed.
2021-11-25 11:55:11 -07:00
*DiagnosticChanged*
feat(diagnostic): pass diagnostics as data to DiagnosticChanged autocmd (#20173)
2022-09-13 07:33:39 -07:00
DiagnosticChanged After diagnostics have changed. When used from Lua,
the new diagnostics are passed to the autocmd
callback in the "data" table.
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
docs: add language annotation to Nvim manual
2022-11-22 10:41:00 -07:00
Example: >lua
feat(diagnostic): pass diagnostics as data to DiagnosticChanged autocmd (#20173)
2022-09-13 07:33:39 -07:00
vim.api.nvim_create_autocmd('DiagnosticChanged', {
callback = function(args)
local diagnostics = args.data.diagnostics
refactor!: rename vim.pretty_print => vim.print Problem: The function name `vim.pretty_print`: 1. is verbose, which partially defeats its purpose as sugar 2. does not draw from existing precedent or any sort of convention (except external projects like penlight or python?), which reduces discoverability, and degrades signaling about best practices. Solution: - Rename to `vim.print`. - Change the behavior so that 1. strings are printed without quotes 2. each arg is printed on its own line 3. tables are indented with 2 instead of 4 spaces - Example: :lua ='a', 'b', 42, {a=3} a b 42 { a = 3 } Comparison of alternatives: - `vim.print`: - pro: consistent with Lua's `print()` - pro: aligns with potential `nvim_print` API function which will replace nvim_echo, nvim_notify, etc. - con: behaves differently than Lua's `print()`, slightly misleading? - `vim.echo`: - pro: `:echo` has similar "pretty print" behavior. - con: inconsistent with Lua idioms. - `vim.p`: - pro: very short, fits with `vim.o`, etc. - con: not as discoverable as "echo" - con: less opportunity for `local p = vim.p` because of potential shadowing.
2023-03-07 08:04:57 -07:00
vim.print(diagnostics)
feat(diagnostic): pass diagnostics as data to DiagnosticChanged autocmd (#20173)
2022-09-13 07:33:39 -07:00
end,
})
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
<
docs(diagnostic): add blurb on how to replace builtin handlers
2021-09-25 08:52:20 -07:00
==============================================================================
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
Lua module: vim.diagnostic *diagnostic-api*
config({opts}, {namespace}) *vim.diagnostic.config()*
Configure diagnostic options globally or for a specific diagnostic
namespace.
fix(diagnostic): do not override existing config settings #16043 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".
2021-10-17 07:18:35 -07:00
Configuration can be specified globally, per-namespace, or ephemerally
(i.e. only for a single call to |vim.diagnostic.set()| or
|vim.diagnostic.show()|). Ephemeral configuration has highest priority,
followed by namespace configuration, and finally global configuration.
docs(gen): support language annotation in docstrings
2022-11-23 04:31:49 -07:00
For example, if a user enables virtual text globally with >lua
docs: replace <pre> with ``` (#25136)
2023-09-14 06:23:01 -07:00
vim.diagnostic.config({ virtual_text = true })
fix(diagnostic): do not override existing config settings #16043 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".
2021-10-17 07:18:35 -07:00
<
docs(gen): support language annotation in docstrings
2022-11-23 04:31:49 -07:00
and a diagnostic producer sets diagnostics with >lua
docs: replace <pre> with ``` (#25136)
2023-09-14 06:23:01 -07:00
vim.diagnostic.set(ns, 0, diagnostics, { virtual_text = false })
fix(diagnostic): do not override existing config settings #16043 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".
2021-10-17 07:18:35 -07:00
<
then virtual text will not be enabled for those diagnostics.
docs: regenerate
2022-08-11 05:25:48 -07:00
docs: gather @notes items into one section related: 21eacbfef399
2023-07-06 13:47:27 -07:00
Note: ~
• Each of the configuration options below accepts one of the following:
docs: remove extra whitespaces
2022-03-13 05:48:14 -07:00
• `false`: Disable this feature
• `true`: Enable this feature, use default settings.
• `table`: Enable this feature with overrides. Use an empty table to
fix(diagnostic): do not override existing config settings #16043 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".
2021-10-17 07:18:35 -07:00
use default values.
docs: remove extra whitespaces
2022-03-13 05:48:14 -07:00
• `function`: Function with signature (namespace, bufnr) that returns
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
any of the above.
docs: regenerate
2022-08-11 05:25:48 -07:00
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
Parameters: ~
feat(docs): format parameters as a list #20485 Problem: The {foo} parameters listed in `:help api` and similar generated docs, are intended to be a "list" but they aren't prefixed with a list symbol. This prevents parsers from understanding the list, which forces generators like `gen_help_html.lua` to use hard-wrapped/preformatted layout instead of a soft-wrapped "flow" layout. Solution: Modify gen_vimdoc.py to prefix {foo} parameters with a "•" symbol.
2022-10-05 05:15:55 -07:00
• {opts} (table|nil) When omitted or "nil", retrieve the current
build(lua2dox): add parenthesis around parameter types in documentation (#18532) This will check if the string after the variable in a @param is either "number", "string", "table", "boolean" and "function" and if so add a parenthesis around it. This will help separate the variable type with the following text. Had all our functions been annotated with emmylua then a more robust solution might have been preferable (such as always assuming the third string is parameter type without making any checks). I believe however this is a clear improvement over the current situation and will suffice for now.
2022-05-12 07:02:46 -07:00
configuration. Otherwise, a configuration table with the
feat(diagnostic): allow retrieving current diagnostic config
2022-01-11 16:44:31 -07:00
following keys:
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
• underline: (default true) Use underline for
fix(diagnostic): support severity_sort
2021-09-17 09:50:25 -07:00
diagnostics. Options:
• severity: Only underline diagnostics matching the
given severity |diagnostic-severity|
docs: regenerate
2022-08-11 05:25:48 -07:00
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
• virtual_text: (default true) Use virtual text for
fix(diagnostic): support severity_sort
2021-09-17 09:50:25 -07:00
diagnostics. If multiple diagnostics are set for a
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
namespace, one prefix per diagnostic + the last
feat(diagnostic): provide more control over virtual text display (#24724) Allow users to pass virtual text options to nvim_buf_set_extmark through the "virtual_text" table in vim.diagnostic.config(). Fixes: https://github.com/neovim/neovim/issues/16545
2023-08-16 06:21:32 -07:00
diagnostic message are shown. In addition to the
options listed below, the "virt_text" options of
|nvim_buf_set_extmark()| may also be used here (e.g.
"virt_text_pos" and "hl_mode"). Options:
fix(diagnostic): support severity_sort
2021-09-17 09:50:25 -07:00
• severity: Only show virtual text for diagnostics
matching the given severity |diagnostic-severity|
fix(diagnostic): respect "if_many" source option for virtual text (#16653) The `prefix_source` function only evaluates the sources from the diagnostics passed to it; however, because each namespace draws its own virtual text, its diagnostics will never contain more than a single source (by definition). This requires changing the semantics of what "if_many" means from "multiple sources in a single 'batch' of diagnostics" to "multiple sources of all diagnostics within a buffer".
2021-12-17 19:38:33 -07:00
• source: (boolean or string) Include the diagnostic
source in virtual text. Use "if_many" to only show
sources if there is more than one diagnostic source
in the buffer. Otherwise, any truthy value means to
always show the diagnostic source.
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
• spacing: (number) Amount of empty spaces inserted at
fix(diagnostic): do not override existing config settings #16043 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".
2021-10-17 07:18:35 -07:00
the beginning of the virtual text.
feat(diagnostic): specify diagnostic virtual text prefix as a function - vim.diagnostic.config() now accepts a function for the virtual_text.prefix option, which allows for rendering e.g., diagnostic severities differently.
2023-04-17 04:53:34 -07:00
• prefix: (string or function) prepend diagnostic
message with prefix. If a function, it must have the
fix(diagnostic): virtual_text prefix function should have index and total (#25801) 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.
2023-10-27 06:17:46 -07:00
signature (diagnostic, i, total) -> string, where
{diagnostic} is of type |diagnostic-structure|, {i}
is the index of the diagnostic being evaluated, and
{total} is the total number of diagnostics for the
line. This can be used to render diagnostic symbols
or error codes.
feat(diagnostic): add `suffix` option to `virt_text` config (#21140) This introduces a `suffix` option to the `virt_text` config in `vim.diagnostic.config()`. The suffix can either be a string which is appended to the diagnostic message or a function returning such. The function receives a `diagnostic` argument, which is the diagnostic table of the last diagnostic (the one whose message is rendered as virt text).
2022-11-20 16:57:36 -07:00
• suffix: (string or function) Append diagnostic
message with suffix. If a function, it must have the
signature (diagnostic) -> string, where {diagnostic}
is of type |diagnostic-structure|. This can be used
to render an LSP diagnostic error code.
feat(diagnostic): allow customized diagnostic messages (#15742) Provide a 'format' option for virtual text and floating window previews that allows the displayed text of a diagnostic to be customized.
2021-09-22 12:20:15 -07:00
• format: (function) A function that takes a diagnostic
as input and returns a string. The return value is
docs(gen): support language annotation in docstrings
2022-11-23 04:31:49 -07:00
the text used to display the diagnostic. Example: >lua
docs: regenerate
2022-08-11 05:25:48 -07:00
docs(gen): support language annotation in docstrings
2022-11-23 04:31:49 -07:00
function(diagnostic)
if diagnostic.severity == vim.diagnostic.severity.ERROR then
return string.format("E: %s", diagnostic.message)
end
return diagnostic.message
feat(diagnostic): allow customized diagnostic messages (#15742) Provide a 'format' option for virtual text and floating window previews that allows the displayed text of a diagnostic to be customized.
2021-09-22 12:20:15 -07:00
end
<
fix(diagnostic): support severity_sort
2021-09-17 09:50:25 -07:00
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
• signs: (default true) Use signs for diagnostics.
fix(diagnostic): support severity_sort
2021-09-17 09:50:25 -07:00
Options:
• severity: Only show signs for diagnostics matching
the given severity |diagnostic-severity|
docs(diagnostics): add "priority" option to signs table (#15860) This feature was added in #15785, but the docs for vim.diagnostic.config() weren't updated.
2021-10-01 18:07:55 -07:00
• priority: (number, default 10) Base priority to use
for signs. When {severity_sort} is used, the priority
of a sign is adjusted based on its severity.
Otherwise, all signs use the same priority.
refactor(diagnostic): set sign by using extmark (#26193) after sign implementation refactor by using extmark, we can use `nvim_buf_set_extmark` to set diagnostic sign instead use `sign_define`
2023-12-13 07:19:53 -07:00
• text: (table) A table mapping |diagnostic-severity|
to the sign text to display in the sign column. The
default is to use "E", "W", "I", and "H" for errors,
warnings, information, and hints, respectively.
Example: >lua
docs(diagnostic): fix typo in example
2023-12-13 08:43:27 -07:00
vim.diagnostic.config({
signs = { text = { [vim.diagnostic.severity.ERROR] = 'E', ... } }
})
refactor(diagnostic): set sign by using extmark (#26193) after sign implementation refactor by using extmark, we can use `nvim_buf_set_extmark` to set diagnostic sign instead use `sign_define`
2023-12-13 07:19:53 -07:00
<
feat(diagnostics): support numhl and linehl for diagnostic signs
2023-12-13 08:54:04 -07:00
• numhl: (table) A table mapping |diagnostic-severity|
to the highlight group used for the line number where
the sign is placed.
• linehl: (table) A table mapping |diagnostic-severity|
to the highlight group used for the whole line the
sign is placed in.
docs: regenerate
2022-08-11 05:25:48 -07:00
refactor(diagnostic)!: replace 'show_*' functions with 'open_float' (#16057) '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
2021-10-19 10:45:51 -07:00
• float: Options for floating windows. See
feat(diagnostic): allow 'prefix' option to return highlight Extend the 'prefix' option for `open_float` to also provide an optional highlight group for the prefix string.
2021-11-15 08:55:31 -07:00
|vim.diagnostic.open_float()|.
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
• update_in_insert: (default false) Update diagnostics in
Insert mode (if false, diagnostics are updated on
InsertLeave)
• severity_sort: (default false) Sort diagnostics by
severity. This affects the order in which signs and
fix(diagnostic): change default severity_sort order 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.
2021-09-17 13:59:30 -07:00
virtual text are displayed. When true, higher
severities are displayed before lower severities (e.g.
ERROR is displayed before WARN). Options:
fix(diagnostic): support severity_sort
2021-09-17 09:50:25 -07:00
• reverse: (boolean) Reverse sort order
docs(diagnostic): number → integer (#22512)
2023-03-04 06:06:20 -07:00
• {namespace} (integer|nil) Update the options for the given namespace.
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
When omitted, update the global diagnostic options.
docs(diagnostic): add return value of `vim.diagnostic.config()` (#26615)
2023-12-17 17:11:47 -07:00
Return: ~
(table|nil) table of current diagnostic config if `opts` is omitted.
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
disable({bufnr}, {namespace}) *vim.diagnostic.disable()*
Disable diagnostics in the given buffer.
Parameters: ~
docs(diagnostic): number → integer (#22512)
2023-03-04 06:06:20 -07:00
• {bufnr} (integer|nil) Buffer number, or 0 for current buffer.
When omitted, disable diagnostics in all buffers.
• {namespace} (integer|nil) Only disable diagnostics for the given
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
namespace.
enable({bufnr}, {namespace}) *vim.diagnostic.enable()*
Enable diagnostics in the given buffer.
Parameters: ~
docs(diagnostic): number → integer (#22512)
2023-03-04 06:06:20 -07:00
• {bufnr} (integer|nil) Buffer number, or 0 for current buffer.
When omitted, enable diagnostics in all buffers.
• {namespace} (integer|nil) Only enable diagnostics for the given
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
namespace.
feat(diagnostic): match(), tolist(), fromlist() #15704 * 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()
2021-09-19 15:13:23 -07:00
fromqflist({list}) *vim.diagnostic.fromqflist()*
Convert a list of quickfix items to a list of diagnostics.
Parameters: ~
fix(lua): improve annotations for stricter luals diagnostics (#24609) Problem: luals returns stricter diagnostics with bundled luarc.json Solution: Improve some function and type annotations: * use recognized uv.* types * disable diagnostic for global `vim` in shared.lua * docs: don't start comment lines with taglink (otherwise LuaLS will interpret it as a type) * add type alias for lpeg pattern * fix return annotation for `vim.secure.trust` * rename local Range object in vim.version (shadows `Range` in vim.treesitter) * fix some "missing fields" warnings * add missing required fields for test functions in eval.lua * rename lsp meta files for consistency
2023-08-09 02:06:13 -07:00
• {list} table[] List of quickfix items from |getqflist()| or
build(lua2dox): add parenthesis around parameter types in documentation (#18532) This will check if the string after the variable in a @param is either "number", "string", "table", "boolean" and "function" and if so add a parenthesis around it. This will help separate the variable type with the following text. Had all our functions been annotated with emmylua then a more robust solution might have been preferable (such as always assuming the third string is parameter type without making any checks). I believe however this is a clear improvement over the current situation and will suffice for now.
2022-05-12 07:02:46 -07:00
|getloclist()|.
feat(diagnostic): match(), tolist(), fromlist() #15704 * 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()
2021-09-19 15:13:23 -07:00
Return: ~
fix(diagnostic): correct type annotations; add Diagnostic type (#21120) Some functions didn't include the `nil` case in the return type annotation. This corrects those and also adds a Diagnostic class definition for the diagnostic.get return type
2022-11-21 14:02:18 -07:00
Diagnostic [] array of |diagnostic-structure|
feat(diagnostic): match(), tolist(), fromlist() #15704 * 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()
2021-09-19 15:13:23 -07:00
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
get({bufnr}, {opts}) *vim.diagnostic.get()*
Get current diagnostics.
docs: regenerate
2022-08-11 05:25:48 -07:00
fix(diagnostic): always return copies of diagnostic items (#25010)
2023-09-06 10:54:18 -07:00
Modifying diagnostics in the returned table has no effect. To set
diagnostics in a buffer, use |vim.diagnostic.set()|.
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
Parameters: ~
docs(diagnostic): number → integer (#22512)
2023-03-04 06:06:20 -07:00
• {bufnr} (integer|nil) Buffer number to get diagnostics from. Use 0
for current buffer or nil for all buffers.
feat(docs): format parameters as a list #20485 Problem: The {foo} parameters listed in `:help api` and similar generated docs, are intended to be a "list" but they aren't prefixed with a list symbol. This prevents parsers from understanding the list, which forces generators like `gen_help_html.lua` to use hard-wrapped/preformatted layout instead of a soft-wrapped "flow" layout. Solution: Modify gen_vimdoc.py to prefix {foo} parameters with a "•" symbol.
2022-10-05 05:15:55 -07:00
• {opts} (table|nil) A table with the following keys:
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
• namespace: (number) Limit diagnostics to the given
namespace.
• lnum: (number) Limit diagnostics to the given line number.
• severity: See |diagnostic-severity|.
docs: regenerate
2022-08-11 05:25:48 -07:00
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
Return: ~
docs(diagnostic): return value of get() #24144
2023-06-27 08:14:17 -07:00
Diagnostic [] table A list of diagnostic items |diagnostic-structure|. Keys `bufnr` , `end_lnum` , `end_col` , and `severity` are guaranteed to be present.
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
refactor(diagnostic): make display handlers generic (#16137) 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.
2021-10-29 18:47:34 -07:00
get_namespace({namespace}) *vim.diagnostic.get_namespace()*
Get namespace metadata.
Parameters: ~
docs(diagnostic): number → integer (#22512)
2023-03-04 06:06:20 -07:00
• {namespace} (integer) Diagnostic namespace
refactor(diagnostic): make display handlers generic (#16137) 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.
2021-10-29 18:47:34 -07:00
Return: ~
build(lua2dox): add parenthesis around parameter types in documentation (#18532) This will check if the string after the variable in a @param is either "number", "string", "table", "boolean" and "function" and if so add a parenthesis around it. This will help separate the variable type with the following text. Had all our functions been annotated with emmylua then a more robust solution might have been preferable (such as always assuming the third string is parameter type without making any checks). I believe however this is a clear improvement over the current situation and will suffice for now.
2022-05-12 07:02:46 -07:00
(table) Namespace metadata
refactor(diagnostic): make display handlers generic (#16137) 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.
2021-10-29 18:47:34 -07:00
docs: regenerate #15545
2021-10-05 10:48:48 -07:00
get_namespaces() *vim.diagnostic.get_namespaces()*
Get current diagnostic namespaces.
Return: ~
build(lua2dox): add parenthesis around parameter types in documentation (#18532) This will check if the string after the variable in a @param is either "number", "string", "table", "boolean" and "function" and if so add a parenthesis around it. This will help separate the variable type with the following text. Had all our functions been annotated with emmylua then a more robust solution might have been preferable (such as always assuming the third string is parameter type without making any checks). I believe however this is a clear improvement over the current situation and will suffice for now.
2022-05-12 07:02:46 -07:00
(table) A list of active diagnostic namespaces |vim.diagnostic|.
docs: regenerate #15545
2021-10-05 10:48:48 -07:00
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
get_next({opts}) *vim.diagnostic.get_next()*
Get the next diagnostic closest to the cursor position.
Parameters: ~
fix(diagnostic): correct type annotations; add Diagnostic type (#21120) Some functions didn't include the `nil` case in the return type annotation. This corrects those and also adds a Diagnostic class definition for the diagnostic.get return type
2022-11-21 14:02:18 -07:00
• {opts} (table|nil) See |vim.diagnostic.goto_next()|
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
Return: ~
fix(diagnostic): correct type annotations; add Diagnostic type (#21120) Some functions didn't include the `nil` case in the return type annotation. This corrects those and also adds a Diagnostic class definition for the diagnostic.get return type
2022-11-21 14:02:18 -07:00
Diagnostic|nil Next diagnostic
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
get_next_pos({opts}) *vim.diagnostic.get_next_pos()*
Return the position of the next diagnostic in the current buffer.
Parameters: ~
fix(diagnostic): correct type annotations; add Diagnostic type (#21120) Some functions didn't include the `nil` case in the return type annotation. This corrects those and also adds a Diagnostic class definition for the diagnostic.get return type
2022-11-21 14:02:18 -07:00
• {opts} (table|nil) See |vim.diagnostic.goto_next()|
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
Return: ~
fix(diagnostic): correct type annotations; add Diagnostic type (#21120) Some functions didn't include the `nil` case in the return type annotation. This corrects those and also adds a Diagnostic class definition for the diagnostic.get return type
2022-11-21 14:02:18 -07:00
table|false Next diagnostic position as a (row, col) tuple or false if
no next diagnostic.
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
get_prev({opts}) *vim.diagnostic.get_prev()*
Get the previous diagnostic closest to the cursor position.
Parameters: ~
fix(diagnostic): correct type annotations; add Diagnostic type (#21120) Some functions didn't include the `nil` case in the return type annotation. This corrects those and also adds a Diagnostic class definition for the diagnostic.get return type
2022-11-21 14:02:18 -07:00
• {opts} nil|table See |vim.diagnostic.goto_next()|
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
Return: ~
fix(diagnostic): correct type annotations; add Diagnostic type (#21120) Some functions didn't include the `nil` case in the return type annotation. This corrects those and also adds a Diagnostic class definition for the diagnostic.get return type
2022-11-21 14:02:18 -07:00
Diagnostic|nil Previous diagnostic
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
get_prev_pos({opts}) *vim.diagnostic.get_prev_pos()*
Return the position of the previous diagnostic in the current buffer.
Parameters: ~
fix(diagnostic): correct type annotations; add Diagnostic type (#21120) Some functions didn't include the `nil` case in the return type annotation. This corrects those and also adds a Diagnostic class definition for the diagnostic.get return type
2022-11-21 14:02:18 -07:00
• {opts} (table|nil) See |vim.diagnostic.goto_next()|
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
Return: ~
fix(diagnostic): correct type annotations; add Diagnostic type (#21120) Some functions didn't include the `nil` case in the return type annotation. This corrects those and also adds a Diagnostic class definition for the diagnostic.get return type
2022-11-21 14:02:18 -07:00
table|false Previous diagnostic position as a (row, col) tuple or
false if there is no prior diagnostic
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
goto_next({opts}) *vim.diagnostic.goto_next()*
Move to the next diagnostic.
docs: regenerate
2022-08-11 05:25:48 -07:00
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
Parameters: ~
feat(docs): format parameters as a list #20485 Problem: The {foo} parameters listed in `:help api` and similar generated docs, are intended to be a "list" but they aren't prefixed with a list symbol. This prevents parsers from understanding the list, which forces generators like `gen_help_html.lua` to use hard-wrapped/preformatted layout instead of a soft-wrapped "flow" layout. Solution: Modify gen_vimdoc.py to prefix {foo} parameters with a "•" symbol.
2022-10-05 05:15:55 -07:00
• {opts} (table|nil) Configuration table with the following keys:
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
• namespace: (number) Only consider diagnostics from the given
namespace.
• cursor_position: (cursor position) Cursor position as a
(row, col) tuple. See |nvim_win_get_cursor()|. Defaults to
the current cursor position.
• wrap: (boolean, default true) Whether to loop around file or
not. Similar to 'wrapscan'.
• severity: See |diagnostic-severity|.
refactor(diagnostic)!: replace 'show_*' functions with 'open_float' (#16057) '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
2021-10-19 10:45:51 -07:00
• float: (boolean or table, default true) If "true", call
|vim.diagnostic.open_float()| after moving. If a table, pass
the table as the {opts} parameter to
|vim.diagnostic.open_float()|. Unless overridden, the float
docs: regenerate (#16390) Co-authored-by: marvim <marvim@users.noreply.github.com>
2021-11-27 09:26:49 -07:00
will show diagnostics at the new cursor position (as if
"cursor" were passed to the "scope" option).
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
• win_id: (number, default 0) Window ID
goto_prev({opts}) *vim.diagnostic.goto_prev()*
Move to the previous diagnostic in the current buffer.
Parameters: ~
fix(docs): nil as viable argument for goto_prev (#20852) Added `nil` as a possible option to `vim.diagnostics.goto_prev` in the docs
2022-10-28 16:13:27 -07:00
• {opts} (table|nil) See |vim.diagnostic.goto_next()|
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
hide({namespace}, {bufnr}) *vim.diagnostic.hide()*
Hide currently displayed diagnostics.
This only clears the decorations displayed in the buffer. Diagnostics can
be redisplayed with |vim.diagnostic.show()|. To completely remove
diagnostics, use |vim.diagnostic.reset()|.
To hide diagnostics and prevent them from re-displaying, use
|vim.diagnostic.disable()|.
Parameters: ~
docs(diagnostic): number → integer (#22512)
2023-03-04 06:06:20 -07:00
• {namespace} (integer|nil) Diagnostic namespace. When omitted, hide diagnostics from all
fix(diagnostic): correct type annotations; add Diagnostic type (#21120) Some functions didn't include the `nil` case in the return type annotation. This corrects those and also adds a Diagnostic class definition for the diagnostic.get return type
2022-11-21 14:02:18 -07:00
namespaces.
docs(diagnostic): number → integer (#22512)
2023-03-04 06:06:20 -07:00
• {bufnr} (integer|nil) Buffer number, or 0 for current buffer.
When omitted, hide diagnostics in all buffers.
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
feat(diagnostic): vim.diagnostic.is_disabled() #21527
2023-01-12 09:57:39 -07:00
is_disabled({bufnr}, {namespace}) *vim.diagnostic.is_disabled()*
Check whether diagnostics are disabled in a given buffer.
Parameters: ~
docs(diagnostic): number → integer (#22512)
2023-03-04 06:06:20 -07:00
• {bufnr} (integer|nil) Buffer number, or 0 for current buffer.
• {namespace} (integer|nil) Diagnostic namespace. When omitted, checks if all diagnostics are
feat(diagnostic): vim.diagnostic.is_disabled() #21527
2023-01-12 09:57:39 -07:00
disabled in {bufnr}. Otherwise, only checks if
diagnostics from {namespace} are disabled.
Return: ~
(boolean)
feat(diagnostic): match(), tolist(), fromlist() #15704 * 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()
2021-09-19 15:13:23 -07:00
*vim.diagnostic.match()*
match({str}, {pat}, {groups}, {severity_map}, {defaults})
Parse a diagnostic from a string.
For example, consider a line of output from a linter: >
docs: replace <pre> with ``` (#25136)
2023-09-14 06:23:01 -07:00
WARNING filename:27:3: Variable 'foo' does not exist
fix(diagnostic): do not override existing config settings #16043 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".
2021-10-17 07:18:35 -07:00
<
feat(diagnostic): match(), tolist(), fromlist() #15704 * 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()
2021-09-19 15:13:23 -07:00
docs(gen): support language annotation in docstrings
2022-11-23 04:31:49 -07:00
This can be parsed into a diagnostic |diagnostic-structure| with: >lua
docs: replace <pre> with ``` (#25136)
2023-09-14 06:23:01 -07:00
local s = "WARNING filename:27:3: Variable 'foo' does not exist"
local pattern = "^(%w+) %w+:(%d+):(%d+): (.+)$"
local groups = { "severity", "lnum", "col", "message" }
vim.diagnostic.match(s, pattern, groups, { WARNING = vim.diagnostic.WARN })
feat(diagnostic): match(), tolist(), fromlist() #15704 * 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()
2021-09-19 15:13:23 -07:00
<
Parameters: ~
feat(docs): format parameters as a list #20485 Problem: The {foo} parameters listed in `:help api` and similar generated docs, are intended to be a "list" but they aren't prefixed with a list symbol. This prevents parsers from understanding the list, which forces generators like `gen_help_html.lua` to use hard-wrapped/preformatted layout instead of a soft-wrapped "flow" layout. Solution: Modify gen_vimdoc.py to prefix {foo} parameters with a "•" symbol.
2022-10-05 05:15:55 -07:00
• {str} (string) String to parse diagnostics from.
• {pat} (string) Lua pattern with capture groups.
• {groups} (table) List of fields in a |diagnostic-structure| to
feat(diagnostic): match(), tolist(), fromlist() #15704 * 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()
2021-09-19 15:13:23 -07:00
associate with captures from {pat}.
feat(docs): format parameters as a list #20485 Problem: The {foo} parameters listed in `:help api` and similar generated docs, are intended to be a "list" but they aren't prefixed with a list symbol. This prevents parsers from understanding the list, which forces generators like `gen_help_html.lua` to use hard-wrapped/preformatted layout instead of a soft-wrapped "flow" layout. Solution: Modify gen_vimdoc.py to prefix {foo} parameters with a "•" symbol.
2022-10-05 05:15:55 -07:00
• {severity_map} (table) A table mapping the severity field from
feat(diagnostic): match(), tolist(), fromlist() #15704 * 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()
2021-09-19 15:13:23 -07:00
{groups} with an item from |vim.diagnostic.severity|.
feat(docs): format parameters as a list #20485 Problem: The {foo} parameters listed in `:help api` and similar generated docs, are intended to be a "list" but they aren't prefixed with a list symbol. This prevents parsers from understanding the list, which forces generators like `gen_help_html.lua` to use hard-wrapped/preformatted layout instead of a soft-wrapped "flow" layout. Solution: Modify gen_vimdoc.py to prefix {foo} parameters with a "•" symbol.
2022-10-05 05:15:55 -07:00
• {defaults} (table|nil) Table of default values for any fields not
build(lua2dox): add parenthesis around parameter types in documentation (#18532) This will check if the string after the variable in a @param is either "number", "string", "table", "boolean" and "function" and if so add a parenthesis around it. This will help separate the variable type with the following text. Had all our functions been annotated with emmylua then a more robust solution might have been preferable (such as always assuming the third string is parameter type without making any checks). I believe however this is a clear improvement over the current situation and will suffice for now.
2022-05-12 07:02:46 -07:00
listed in {groups}. When omitted, numeric values
feat(diagnostic): match(), tolist(), fromlist() #15704 * 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()
2021-09-19 15:13:23 -07:00
default to 0 and "severity" defaults to ERROR.
docs: regenerate
2022-08-11 05:25:48 -07:00
feat(diagnostic): match(), tolist(), fromlist() #15704 * 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()
2021-09-19 15:13:23 -07:00
Return: ~
fix(diagnostic): correct type annotations; add Diagnostic type (#21120) Some functions didn't include the `nil` case in the return type annotation. This corrects those and also adds a Diagnostic class definition for the diagnostic.get return type
2022-11-21 14:02:18 -07:00
Diagnostic|nil: |diagnostic-structure| or `nil` if {pat} fails to
match {str}.
feat(diagnostic): match(), tolist(), fromlist() #15704 * 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()
2021-09-19 15:13:23 -07:00
refactor(diagnostic): remove bufnr parameter from open_float (#16579) 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.
2021-12-08 18:44:31 -07:00
open_float({opts}, {...}) *vim.diagnostic.open_float()*
refactor(diagnostic)!: replace 'show_*' functions with 'open_float' (#16057) '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
2021-10-19 10:45:51 -07:00
Show diagnostics in a floating window.
docs: regenerate
2022-08-11 05:25:48 -07:00
refactor(diagnostic)!: replace 'show_*' functions with 'open_float' (#16057) '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
2021-10-19 10:45:51 -07:00
Parameters: ~
feat(docs): format parameters as a list #20485 Problem: The {foo} parameters listed in `:help api` and similar generated docs, are intended to be a "list" but they aren't prefixed with a list symbol. This prevents parsers from understanding the list, which forces generators like `gen_help_html.lua` to use hard-wrapped/preformatted layout instead of a soft-wrapped "flow" layout. Solution: Modify gen_vimdoc.py to prefix {foo} parameters with a "•" symbol.
2022-10-05 05:15:55 -07:00
• {opts} (table|nil) Configuration table with the same keys as
refactor(diagnostic): remove bufnr parameter from open_float (#16579) 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.
2021-12-08 18:44:31 -07:00
|vim.lsp.util.open_floating_preview()| in addition to the
following:
• bufnr: (number) Buffer number to show diagnostics from.
Defaults to the current buffer.
• namespace: (number) Limit diagnostics to the given namespace
• scope: (string, default "line") Show diagnostics from the
whole buffer ("buffer"), the current cursor line ("line"),
or the current cursor position ("cursor"). Shorthand
versions are also accepted ("c" for "cursor", "l" for
"line", "b" for "buffer").
• pos: (number or table) If {scope} is "line" or "cursor", use
this position rather than the cursor position. If a number,
interpreted as a line number; otherwise, a (row, col) tuple.
• severity_sort: (default false) Sort diagnostics by severity.
Overrides the setting from |vim.diagnostic.config()|.
• severity: See |diagnostic-severity|. Overrides the setting
from |vim.diagnostic.config()|.
• header: (string or table) String to use as the header for
the floating window. If a table, it is interpreted as a
[text, hl_group] tuple. Overrides the setting from
|vim.diagnostic.config()|.
fix(diagnostic): respect "if_many" source option for virtual text (#16653) The `prefix_source` function only evaluates the sources from the diagnostics passed to it; however, because each namespace draws its own virtual text, its diagnostics will never contain more than a single source (by definition). This requires changing the semantics of what "if_many" means from "multiple sources in a single 'batch' of diagnostics" to "multiple sources of all diagnostics within a buffer".
2021-12-17 19:38:33 -07:00
• source: (boolean or string) Include the diagnostic source in
the message. Use "if_many" to only show sources if there is
more than one source of diagnostics in the buffer.
Otherwise, any truthy value means to always show the
diagnostic source. Overrides the setting from
refactor(diagnostic): remove bufnr parameter from open_float (#16579) 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.
2021-12-08 18:44:31 -07:00
|vim.diagnostic.config()|.
• format: (function) A function that takes a diagnostic as
input and returns a string. The return value is the text
used to display the diagnostic. Overrides the setting from
|vim.diagnostic.config()|.
• prefix: (function, string, or table) Prefix each diagnostic
in the floating window. If a function, it must have the
signature (diagnostic, i, total) -> (string, string), where
{i} is the index of the diagnostic being evaluated and
{total} is the total number of diagnostics displayed in the
window. The function should return a string which is
prepended to each diagnostic in the window as well as an
(optional) highlight group which will be used to highlight
the prefix. If {prefix} is a table, it is interpreted as a
[text, hl_group] tuple as in |nvim_echo()|; otherwise, if
{prefix} is a string, it is prepended to each diagnostic in
the window with no highlight. Overrides the setting from
|vim.diagnostic.config()|.
feat(diagnostic): add `suffix` option to `open_float()` (#21130) Closes #18687 This introduces a `suffix` option to `vim.diagnostic.open_float()` (and consequently `vim.diagnostic.config()`) that appends some text to each diagnostic in the float. It accepts the same types as `prefix`. For multiline diagnostics, the suffix is only appended to the last line. By default, the suffix will render the diagnostic error code, if any.
2022-11-20 13:09:35 -07:00
• suffix: Same as {prefix}, but appends the text to the
diagnostic instead of prepending it. Overrides the setting
from |vim.diagnostic.config()|.
docs: regenerate
2022-08-11 05:25:48 -07:00
refactor(diagnostic)!: replace 'show_*' functions with 'open_float' (#16057) '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
2021-10-19 10:45:51 -07:00
Return: ~
docs(diagnostic): number → integer (#22512)
2023-03-04 06:06:20 -07:00
integer|nil, integer|nil: ({float_bufnr}, {win_id})
refactor(diagnostic)!: replace 'show_*' functions with 'open_float' (#16057) '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
2021-10-19 10:45:51 -07:00
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
reset({namespace}, {bufnr}) *vim.diagnostic.reset()*
Remove all diagnostics from the given namespace.
docs: regenerate
2022-08-11 05:25:48 -07:00
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
Unlike |vim.diagnostic.hide()|, this function removes all saved
diagnostics. They cannot be redisplayed using |vim.diagnostic.show()|. To
simply remove diagnostic decorations in a way that they can be
re-displayed, use |vim.diagnostic.hide()|.
docs: regenerate
2022-08-11 05:25:48 -07:00
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
Parameters: ~
docs(diagnostic): number → integer (#22512)
2023-03-04 06:06:20 -07:00
• {namespace} (integer|nil) Diagnostic namespace. When omitted, remove diagnostics from all
fix(diagnostic): correct type annotations; add Diagnostic type (#21120) Some functions didn't include the `nil` case in the return type annotation. This corrects those and also adds a Diagnostic class definition for the diagnostic.get return type
2022-11-21 14:02:18 -07:00
namespaces.
docs(diagnostic): number → integer (#22512)
2023-03-04 06:06:20 -07:00
• {bufnr} (integer|nil) Remove diagnostics for the given buffer.
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
When omitted, diagnostics are removed for all buffers.
set({namespace}, {bufnr}, {diagnostics}, {opts}) *vim.diagnostic.set()*
Set diagnostics for the given namespace and buffer.
Parameters: ~
docs(diagnostic): number → integer (#22512)
2023-03-04 06:06:20 -07:00
• {namespace} (integer) The diagnostic namespace
• {bufnr} (integer) Buffer number
feat(docs): format parameters as a list #20485 Problem: The {foo} parameters listed in `:help api` and similar generated docs, are intended to be a "list" but they aren't prefixed with a list symbol. This prevents parsers from understanding the list, which forces generators like `gen_help_html.lua` to use hard-wrapped/preformatted layout instead of a soft-wrapped "flow" layout. Solution: Modify gen_vimdoc.py to prefix {foo} parameters with a "•" symbol.
2022-10-05 05:15:55 -07:00
• {diagnostics} (table) A list of diagnostic items
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
|diagnostic-structure|
feat(docs): format parameters as a list #20485 Problem: The {foo} parameters listed in `:help api` and similar generated docs, are intended to be a "list" but they aren't prefixed with a list symbol. This prevents parsers from understanding the list, which forces generators like `gen_help_html.lua` to use hard-wrapped/preformatted layout instead of a soft-wrapped "flow" layout. Solution: Modify gen_vimdoc.py to prefix {foo} parameters with a "•" symbol.
2022-10-05 05:15:55 -07:00
• {opts} (table|nil) Display options to pass to
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
|vim.diagnostic.show()|
setloclist({opts}) *vim.diagnostic.setloclist()*
Add buffer diagnostics to the location list.
docs: regenerate
2022-08-11 05:25:48 -07:00
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
Parameters: ~
feat(docs): format parameters as a list #20485 Problem: The {foo} parameters listed in `:help api` and similar generated docs, are intended to be a "list" but they aren't prefixed with a list symbol. This prevents parsers from understanding the list, which forces generators like `gen_help_html.lua` to use hard-wrapped/preformatted layout instead of a soft-wrapped "flow" layout. Solution: Modify gen_vimdoc.py to prefix {foo} parameters with a "•" symbol.
2022-10-05 05:15:55 -07:00
• {opts} (table|nil) Configuration table with the following keys:
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
• namespace: (number) Only add diagnostics from the given
namespace.
• winnr: (number, default 0) Window number to set location
list for.
• open: (boolean, default true) Open the location list after
setting.
• title: (string) Title of the location list. Defaults to
"Diagnostics".
• severity: See |diagnostic-severity|.
setqflist({opts}) *vim.diagnostic.setqflist()*
Add all diagnostics to the quickfix list.
docs: regenerate
2022-08-11 05:25:48 -07:00
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
Parameters: ~
feat(docs): format parameters as a list #20485 Problem: The {foo} parameters listed in `:help api` and similar generated docs, are intended to be a "list" but they aren't prefixed with a list symbol. This prevents parsers from understanding the list, which forces generators like `gen_help_html.lua` to use hard-wrapped/preformatted layout instead of a soft-wrapped "flow" layout. Solution: Modify gen_vimdoc.py to prefix {foo} parameters with a "•" symbol.
2022-10-05 05:15:55 -07:00
• {opts} (table|nil) Configuration table with the following keys:
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
• namespace: (number) Only add diagnostics from the given
namespace.
• open: (boolean, default true) Open quickfix list after
setting.
• title: (string) Title of quickfix list. Defaults to
"Diagnostics".
• severity: See |diagnostic-severity|.
*vim.diagnostic.show()*
show({namespace}, {bufnr}, {diagnostics}, {opts})
Display diagnostics for the given namespace and buffer.
docs: regenerate
2022-08-11 05:25:48 -07:00
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
Parameters: ~
docs(diagnostic): number → integer (#22512)
2023-03-04 06:06:20 -07:00
• {namespace} (integer|nil) Diagnostic namespace. When omitted, show diagnostics from all
fix(diagnostic): correct type annotations; add Diagnostic type (#21120) Some functions didn't include the `nil` case in the return type annotation. This corrects those and also adds a Diagnostic class definition for the diagnostic.get return type
2022-11-21 14:02:18 -07:00
namespaces.
docs(diagnostic): number → integer (#22512)
2023-03-04 06:06:20 -07:00
• {bufnr} (integer|nil) Buffer number, or 0 for current buffer.
build(lua2dox): add parenthesis around parameter types in documentation (#18532) This will check if the string after the variable in a @param is either "number", "string", "table", "boolean" and "function" and if so add a parenthesis around it. This will help separate the variable type with the following text. Had all our functions been annotated with emmylua then a more robust solution might have been preferable (such as always assuming the third string is parameter type without making any checks). I believe however this is a clear improvement over the current situation and will suffice for now.
2022-05-12 07:02:46 -07:00
When omitted, show diagnostics in all buffers.
feat(docs): format parameters as a list #20485 Problem: The {foo} parameters listed in `:help api` and similar generated docs, are intended to be a "list" but they aren't prefixed with a list symbol. This prevents parsers from understanding the list, which forces generators like `gen_help_html.lua` to use hard-wrapped/preformatted layout instead of a soft-wrapped "flow" layout. Solution: Modify gen_vimdoc.py to prefix {foo} parameters with a "•" symbol.
2022-10-05 05:15:55 -07:00
• {diagnostics} (table|nil) The diagnostics to display. When omitted,
build(lua2dox): add parenthesis around parameter types in documentation (#18532) This will check if the string after the variable in a @param is either "number", "string", "table", "boolean" and "function" and if so add a parenthesis around it. This will help separate the variable type with the following text. Had all our functions been annotated with emmylua then a more robust solution might have been preferable (such as always assuming the third string is parameter type without making any checks). I believe however this is a clear improvement over the current situation and will suffice for now.
2022-05-12 07:02:46 -07:00
use the saved diagnostics for the given namespace and
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
buffer. This can be used to display a list of
diagnostics without saving them or to display only a
feat(diagnostic): do not require namespace for hide() and show() (#16261) 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.
2021-11-09 14:33:01 -07:00
subset of diagnostics. May not be used when {namespace}
refactor(diagnostic): make bufnr arguments consistent (#16323) 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.
2021-11-16 08:47:49 -07:00
or {bufnr} is nil.
feat(docs): format parameters as a list #20485 Problem: The {foo} parameters listed in `:help api` and similar generated docs, are intended to be a "list" but they aren't prefixed with a list symbol. This prevents parsers from understanding the list, which forces generators like `gen_help_html.lua` to use hard-wrapped/preformatted layout instead of a soft-wrapped "flow" layout. Solution: Modify gen_vimdoc.py to prefix {foo} parameters with a "•" symbol.
2022-10-05 05:15:55 -07:00
• {opts} (table|nil) Display options. See
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
|vim.diagnostic.config()|.
feat(diagnostic): match(), tolist(), fromlist() #15704 * 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()
2021-09-19 15:13:23 -07:00
toqflist({diagnostics}) *vim.diagnostic.toqflist()*
Convert a list of diagnostics to a list of quickfix items that can be
passed to |setqflist()| or |setloclist()|.
Parameters: ~
feat(docs): format parameters as a list #20485 Problem: The {foo} parameters listed in `:help api` and similar generated docs, are intended to be a "list" but they aren't prefixed with a list symbol. This prevents parsers from understanding the list, which forces generators like `gen_help_html.lua` to use hard-wrapped/preformatted layout instead of a soft-wrapped "flow" layout. Solution: Modify gen_vimdoc.py to prefix {foo} parameters with a "•" symbol.
2022-10-05 05:15:55 -07:00
• {diagnostics} (table) List of diagnostics |diagnostic-structure|.
feat(diagnostic): match(), tolist(), fromlist() #15704 * 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()
2021-09-19 15:13:23 -07:00
Return: ~
fix(diagnostic): correct type annotations; add Diagnostic type (#21120) Some functions didn't include the `nil` case in the return type annotation. This corrects those and also adds a Diagnostic class definition for the diagnostic.get return type
2022-11-21 14:02:18 -07:00
table[] of quickfix list items |setqflist-what|
feat(diagnostic): match(), tolist(), fromlist() #15704 * 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()
2021-09-19 15:13:23 -07:00
refactor: move vim.lsp.diagnostic to vim.diagnostic 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
2021-09-06 19:21:18 -07:00
vim:tw=78:ts=8:sw=4:sts=4:et:ft=help:norl:
Reference in New Issue Copy Permalink