When buffer is visible in two splits simultaneously, BufHidden event is
not triggered, causing the floating window to remain on screen after
switching to another buffer.
Remove BufHidden event from close_events defaults, and close the window
if we changed the buffer to something other than the buffer that spawned
the floating window or the floating window buffer itself.
Based on https://github.com/neovim/neovim/pull/14445
This extends `vim.treesitter.query.get_node_text` to return the text
that spans a node's range even if start_row ~= end_row.
Calling vim.lsp.buf.definition() sometimes gives a deprecation warning.
This will likely solve that.
Co-authored-by: Christian Clason <christian.clason@uni-due.de>
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.
Closes https://github.com/neovim/neovim/issues/16492
Despite having logic for setting the maximum diagnostic line
number to at minimum 0, previously the conditional statement only
checked if lnum and end_lnum were greater than the line count.
Fix: also check if lnum and end_lnum are less than 0.
The examples are relevant and applicable for both Lua and Vimscript
configurations and the `vim.api.nvim_command` prefixes just add noise
that doesn't contribute to the example.
When the 'focusable' and 'focus_id' parameters are set,
`open_floating_preview` assumes that it should always move focus to an
existing floating window with the same 'focus_id'. However, there are
cases where we want to make a floating window focusable, but do not want
to focus it upon calling `open_floating_preview`. To distinguish these
cases, add a boolean parameter 'focus' that, when false, prevents
moving focus.
When `vim.diagnostic.set()` is called, the diagnostics passed to it are
added to the diagnostic cache. `set()` then calls `show()` and passes
those diagnostics along exactly as they were given to `set()`. However,
we sometimes want to do some kind of post-processing on diagnostics when
they come out of the cache, e.g. clamping line numbers. By forwarding
the diagnostics to `show()` verbatim, `set()` skips this post-processing
which can cause other bugs downstream.
Instead of passing the diagnostics directly, make the `show()` call from
within `set()` retrieve diagnostics from the cache. In general, all
diagnostics operations should follow the pattern of "producers put
things in the cache" and "consumers get things out of the cache" and
this change better adheres to that pattern.
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.
Previously, the built-in language server client checked if the first
argument of cmd was executable via vim.fn.executable. This ignores PATH
injected via cmd_env. Instead, we now start the client via uv.spawn, and
handle the failure mode, reporting the error back to the user.
Co-authored-by: Mathias Fußenegger <mfussenegger@users.noreply.github.com>
Floating windows opened by `goto_next` and `goto_prev` should not be
focused when repeating the `goto_` function. The float can still be
focused by calling `open_float` with `scope = "cursor"`.
Reverts 5b0d8f85fd.
Diagnostic producers can send diagnostics for buffers that are not
loaded, for which we cannot retrieve the line count to clamp line
numbers. This means that some diagnostics in the quickfix list could be
line-clamped and others not. The quickfix list can already handle line
numbers past the end of the buffer (i.e. it *already* clamps line
numbers) so just use the "raw" diagnostic positions sent from the
producer.
04bfd20bb introduced a subtle bug where using 0 as the buffer number in
the diagnostic cache resets the cache for the current buffer. This
happens because we were not checking to see if the _resolved_ buffer
number already existed in the cache; rather, when the __index metamethod
was called we assumed the index did not exist so we set its value to an
empty table. The fix for this is to check `rawget()` for the resolved
buffer number to see if the index already exists.
However, the reason this bug was introduced in the first place was
because we are simply being too clever by allowing a 0 buffer number as
the index which is automatically resolved to a real buffer number.
In the interest of minimizing metatable magic, remove this "feature" by
requiring the buffer number index to always be a valid buffer. This
ensures that the __index metamethod is only ever called for non-existing
buffers (which is what we wanted originally) as well as reduces some of
the cognitive overhead for understanding how the diagnostic cache works.
The tradeoff is that all public API functions must now resolve 0 buffer
numbers to the current buffer number.
Errors were being caused by invalid buffers being kept around in
diagnostic_cache, so add a metatable to diagnostic_cache which attaches
to new buffers in the cache, removing them after they are invalidated.
Closes#16391.
Co-authored-by: Gregory Anders <8965202+gpanders@users.noreply.github.com>
