Problem: when the TUI output buffer is filled during a redraw, flushing
it to the terminal also causes `CSI ? 2026 l` to be emitted, which ends
synchronized output. This causes visible flickering with large redraws.
Solution: track whether a synchronized output is currently active, and
only emit the end sequence on the final flush.
Problem:
Literal tab (or other control char) in a float title/footer is
not made printable, so it renders incorrectly instead of as "^I".
Solution:
Normalize title/footer text for display like 'statusline'
tab to "^I", parameterize parse_virt_text() with untab
and recompute the width.
Problem: Redrawing in an autocommand that uses an autocommand window
(more common since 5181984d) can result in flickering.
Solution: Hide autocommand windows.
Problem:
It is repetitive to map multiple keymaps to do the same thing. Here are some
cases where being able to do this would be useful:
-- Visual movement for both j/k and down/up:
vim.keymap.set({ 'n', 'x' }, { 'j', '<Down>' }, 'v:count == 0 ? "gj" : "j"', { expr = true })
vim.keymap.set({ 'n', 'x' }, { 'k', '<Up>' }, 'v:count == 0 ? "gk" : "k"', { expr = true })
-- Map multiple keys to `<Nop>` concisely:
vim.keymap.set({ 'n', 'x' }, { '<Leader>', '<Localleader>', '<CR>' }, '<Nop>')
-- Remove multiple keymaps at once:
vim.keymap.del('n', { 'gri', 'grn', 'grr' })
Solution:
Support the `lhs` of `vim.keymap.set()` and `vim.keymap.del()` being a table, in
the same way that `modes` can be.
Problem:
Currently, only some filesystems (Btrfs, ext2, ext3, ext4) have full
support of accessing the `dirent` entry-type. On other filesystems,
`uv.fs_scandir_next` may return `nil` for an existing but unsupported
entry-type.
This means consumers (such as `fs.dir()`), cannot know if `nil` means
"non-existent" or "unsupported".
Solution:
Fall back to `uv.fs_lstat` when `etype` is `nil`; return "unknown" if it
fails.
Problem: Redrawing when a loaded buffer is not shown in any window on
the current tabpage.
Solution: Check that buffer is shown in a (normal) window before redrawing.
Problem: Cmdline ruler may be drawn for autocommand window.
Solution: Check that the current window is not an autocommand window
when deciding whether to draw the ruler.
Problem:
The logic for generating the complete item `info` is spread across
`_lsp_to_complete_items`, the `CompleteChanged` event handler, and
`CompletionResolver:request`. This has previously caused the `info`
shown for resolved (via `completionItem/resolve`) and unresolved items
to differ.
Solution:
Centralise the logic in a new `complete_item_info` function which is now
solely responsible for determining:
1. The `info` to show.
2. The markup kind of the `info`.
3. Whether the `info` is complete.
This simplifies the interaction between the 3 functions mentioned in the
problem:
- `_lsp_to_complete_items` calls `complete_item_info` and passes along
the markup kind and whether the item needs resolving via the complete
item's `user_data`.
- The `CompleteChanged` consumes the markup kind and whether the
item needs resolving from the complete item's `user_data`.
- `CompletionResolver:request`, like `_lsp_to_complete_items` calls
`complete_item_info` again and updates the current `info` if it's
changed.
Problem:
`CompletionItem.detail` is only shown in the info popup if the server
supports `completionItem/resolve`.
Solution:
If the server doesn't support `completionItem/resolve`, prepend the
complete item `info` with `CompletionItem.detail` in a fenced codeblock,
same as we do when the server supports `completionItem/resolve`.
To ensure that completion items are displayed in the same way,
regardless of whether the server supports `completionItem/resolve`, i've
extracted out the test logic from the `selecting an item triggers
completionItem/resolve + (snippet) preview` case so that we can run the
same tests against a server which supports `completionItem/resolve` and
one which doesn't. Hopefully this should prevent the two behaviours
diverging again.
Problem:
If `CompletionItem.documentation` is populated but `detail` is not, then
`detail` is not resolved.
Solution:
Ensure that we resolve a `CompletionItem` if either `detail` or
`documentation` are not populated.
I've also removed `detail` from the popup menu since otherwise it will
be populated in both the popup menu and the info popup after the
`CompletionItem` has been resolved. I think the info popup is the best
place for it anyway as when there is a completion item with a long popup
menu entry (when `detail` is a medium/long function signature for
instance), the whole popup menu gets widened and this steals horizontal
space that could be used to display the `documentation`. Now with
`detail` and `documentation` in the info popup, they share the same
horizontal space. This also aligns with how VSCode, nvim-cmp, blink.cmp,
and mini.nvim display `detail`.
Problem:
When a resolved `CompletionItem` with kind `Snippet` populates
`textEdit` instead of `insertText`, the contents are not previewed.
Solution:
Generate the snippet preview from `textEdit.newText` as well.
Problem:
(Followup to 54f22a8f01c0feb27a531b52aedf5cdbd5e51b24.)
Deleting another buffer from a floatwin could move focus into the holder
window and fire BufEnter for the buffer being deleted.
Solution:
Use switch_win_noblock() instead of buf_jump_open_win() before
recursing into do_buffer_ext().
Problem:
`nvim_create_autocmd` is too verbose and its `callback` requires extra
"nesting".
Solution:
Introduce `nvim_on`. Start using it internally. Then we can get a feel
for how it should look before making it public.
Problem: If there are pending messages when starting to build the
runtime search path, a msg_show callback may invoke
runtime_search_path_validate() recursively.
Solution: Avoid msg_show callback by ensuring messages are flushed.
Problem:
Virtual lines above a line where a fold starts show `foldopen` in
`foldcolumn`.
Solution:
Check if the line below the virtual one is inside a fold that starts
higher up or if it's the start of a fold. In the latter case, don't show
anything in `foldcolumn` for the virtual line.
refactor: lint
Problem:
- To share logic, creating a `vim.Range` currently creates two `vim.Pos` values
as intermediates, which causes unnecessary table allocations.
- `pos.lua` and `range.lua` contain some overlapping logic.
Solution:
Add `vim.pos._util`, a module for handling
positions represented directly by `row` and `col`.
Problem: `nvim_exec_autocmds({ buf = ... })` matches the target buffer, but callbacks and modelines run with the caller buffer current rather than the target buffer.
Solution: Execute the buffered path in prepared target-buffer context and restore the caller afterward.
Problem:
When mouse=n is set
- Dragging the mouse enters visual mode, and then stops listening for
mouse events.
- Double/Triple/Quad clicking performs selections.
- Clicking in visual mode moves the cursor (though not through the TUI).
Solution:
Explicitly gate mouse actions that affect visual mode with a check for
MOUSE_VISUAL. This matches the behavior described in :help mouse.
> If enabled for "v" (Visual mode) then double-click selects word-wise,
> triple-click makes it line-wise, and quadruple-click makes it
> rectangular block-wise.
Problem:
Visual selection could end up in the wrong place after
nvim_buf_set_text or nvim_buf_set_lines. In some delete cases,
Visual.lnum was already clamped before the line shift happened, so the
adjustment got skipped.
Solution:
Split fix_cursor_cols into reusable fix_pos_col logic and reuse it
for Visual updates. Also adjust Visual.lnum before changed_lines so
the shift uses the original position before final clamping.
Problem:
After 767fbd8, typing trigger chars would open completion but the
chars were removed.
Solution:
Use filterText fallback so selected item respects typed trigger chars.
Problem:
- Windows users can't use terminfo to configure their terminal
capabilities. #37274
- Terminfo definitions sometimes get out of date or are simply
inaccurate.
- Eventually, we may want to drop terminfo, relying primarily on
built-in definitions. Users will still need some flexibility.
Solution:
Support $NVIM_TERMDEFS environment variable, which is JSON data that
defines "terminfo" definitions that override our builtin terminfo.
Problem:
During startup, we manually trigger a useless and misleading `OptionSet`
event, which doesn't set `v:option_*` values (this is a limitation of
`nvim_exec_autocmds`).
ad4bc2d90c/runtime/lua/vim/_core/defaults.lua (L939).
Solution:
The `nvim_exec_autocmds('OptionSet',…)` call does not serve any purpose
since 5cbb9d613b, so just drop it.
Problem:
PlainText completion items used `textEdit.newText` or `insertText` as
the completion word even when they did not match the typed prefix. This
could break popup completion behavior like 'completeopt+=longest'.
Solution:
Fall back to `filterText` when `newText` or `insertText` does not match
the typed prefix.
Problem: There is currently no convenient way to programmatically check
for new updates from plugin source. Running `vim.pack.update()` is one
approach, but it opens a confirmation buffer that requires a manual
action to close.
Solution: Add `opts.offline` to `vim.pack.get()` that will first fetch
new updates from plugin source before computing the output.
Problem: No convenient way to programmatically get the revision that
would be checked out after `vim.pack.update()` (with `offline=true`).
Doing this manually requires resolving `spec.version` which is not
trivial. This data can be useful for custom reporting of pending
updates or third party confirmation step.
Solution: Make `get()` include a new field for the revision that points
at the state after applying pending update. This is also the same as
the revision of resolved `spec.version`.
Problem: `fnamemodify(..., ':h')` mishandles POSIX leading slash runs longer than `//`.
Solution: Collapse those slash runs to `/` before computing the head.
Problem:
2d795face6 added support for tab-local options ('cmdheight')
to `nvim_get_option_value`, but not to:
nvim_get_option_info2()
nvim_set_option_value(…, { tab = … })
gettabwinvar()
Solution:
- Update `options.lua` to model tab-local options. Introduce `kOptScopeTab`.
- Handle tab scope in the options layer so it works for all options APIs.
Note:
- No change to `gettabvar()`. Not sure if needed/wanted.
fix https://github.com/neovim/neovim/issues/31140
Problem: `vim.pack.get()` always uses lockfile as the source for the
`rev` field. This is fast, but may be misleading in case of
a corrupted lockfile.
Solution: Compute revision from Git repo on disk if `info=true`
(default), use lockfile otherwise. This does increase execution time
(as a result of one extra `git ...` call for every plugin), but
`info=true` is already designed to be informative and not necessarily
fast.
Problem:
No way to handle a "tab moved" event.
Use-case: tabline plugins may cache tab labels, and need to know when to
invalidate their cache.
Solution:
Add a `TabMoved` event that triggers whenever tabs are reordered via `:tabmove`
or via mouse click-and-drag.
Problem:
After closing and reopening Neovim, ]' and [' fail with E92: Buffer 0
not found for marks restored from ShaDa. Direct jumps like 'a work
because mark_get_local() rewrites fnum before returning, but ]' uses
getnextmark() which does not, leaving fnum = 0.
Solution:
Set .fnum = buf->b_fnum when restoring local marks from ShaDa.
Problem: with a float focused and the target buf only shown in the
last non-float window, do_buffer_ext goes down the buf != curbuf
path. close_windows can't touch the last non-float, b_nwindows stays
> 0, close_buffer is skipped, returns OK silently.
Solution: if a non-float still holds buf after close_windows, jump
into it and recurse. Then buf == curbuf and the existing replacement
path takes over.
