Problem: Modifying a hidden buffer still interferes with prompt buffer
mode changes.
Solution: Save and restore b_prompt_insert.
(zeertzjq)
closes: vim/vim#13875
Modifying hidden buffer still interferes with prompt buffer mode changes
f267847017
Problem: too vague errors for 'listchars'/'fillchars'
Solution: Include the field name in error message.
(zeertzjq)
related: #27050closes: vim/vim#138776a8d2e1634
Co-authored-by: Cole Frankenhoff <cole.nhf@gmail.com>
Problem: Wrong "clear" argument passed to buf_signcols_count_range
when initializing "b_signcols.count" for the first time.
Solution: Pass kFalse so that the "nested" counter is not incorrectly
decremented.
Problem: Insert mode not stopped if an autocommand modifies a hidden
buffer while closing a prompt buffer.
Solution: Don't set b_prompt_insert if stop_insert_mode is already set.
(zeertzjq)
closes: vim/vim#1387296958366ad
Problem: The 'statuscolumn' is not redrawn on the wrapped part of a
line when moving the cursor with 'relativenumber' set.
Solution: Redraw the 'statuscolumn' for the entire line height in the
"col_rows" win_line() code path.
The motivation for this update is Issue #15365, where background=light
is not properly set for Nvim running from an Nvim :terminal. This can be
encountered when e.g., opening a terminal to make git commits, which
opens EDITOR=nvim in the nested terminal.
Under the implementation of this commit, the OSC response always
indicates a black or white foreground/background. While this may not
reflect the actual foreground/background color, it permits 'background'
to be retained for a nested Nvim instance running in the terminal
emulator. The behaviour matches Vim.
Problem: Some edge cases to the old (pre-#26406) and current "b_signcols"
structure result in an incorrectly sized "auto" 'signcolumn'.
Solution: * Implement a simpler 'signcolumn' validation strategy by immediately
counting the number of signs in a range upon sign insertion and
deletion. Decrease in performance here but there is a clear path
forward to decreasing this performance hit by moving signs to a
dedicated marktree, or by adding meta-data to the existing
marktree which may be queried more efficiently?
* Also replace "max_count" and keep track of the number of lines with
a certain number of signs. This makes it so that it is no longer
necessary to scan the entire buffer when the maximum number of signs
decreases. This likely makes the commit a net increase in performance.
* To ensure correctness we also have re-initialize the count for an
edited region that spans multiple lines. Such an edit may move the
signs within it. Thus we count and decrement before splicing the
marktree and count and increment after.
Problem: Current values of `StatusLine` and `StatusLineNC` are currently
designed to be visually distinctive while being not intrusive.
However, the compromise was more shifted towards "not intrusive".
After the feedback, statusline highlight groups should be designed to:
- Make current window clearly noticeable. Meaning `StatusLine` and
`StatusLineNC` should obviously differ.
- Make non-current windows clearly separable. Meaning `StatusLineNC`
and `Normal`/`NormalNC` should obviously differ.
Solution:
- Update `StatusLineNC` to have more visible background.
- Update `StatusLine` to be inverted variant of `StatusLineNC`.
- Update `WinBar` and `WinBarNC` to not link to `StatusLine` and
`StatusLineNC` because it makes two goals harder to achieve.
- Update `TabLine` to link to `StatusLineNC` instead of `StatusLine`
to not be very visually intrusive.
This commit implements a new TermRequest autocommand event and has Neovim
emit this event when children of terminal buffers emit an OSC or DCS sequence
libvterm does not handle.
The TermRequest autocommand event has additional data in the
v:termrequest variable.
Co-authored-by: Gregory Anders <greg@gpanders.com>
A bit big, but practically it was a lot simpler to change over all
fillchars and all listchars at once, to not need to maintain two
parallel implementations.
This is mostly an internal refactor, but it also removes an arbitrary
limitation: that 'fillchars' and 'listchars' values can only be
single-codepoint characters. Now any character which fits into a single
screen cell can be used.
Since execl() is a variadic function, it requries a NULL-terminal to
indicate the end of its argument list, c.f. exec(3)
> The first argument, by convention, should point to the filename
> associated with the file being executed. The list of arguments *must*
> be terminated by a null pointer
This fixes the failure seen on aarch64 and i386, due to garbage data
being considered part of the variadic arguments.
Problem:
Many decoration providers (treesitter injection highlighting, semantic
token highlighting, inlay hint) rely on the correctness of the `botline`
argument of `on_win` callback. However, `botline` can be smaller than
the actual line number of the last displayed line if some lines are
folded. In such cases, some decorations will be missing in the lines not
covered by `botline`.
Solution:
Validate `botline` when invoking `on_win`.
NOTE:
It seems that the old code was deliberately avoiding this presumably due
to performance reasons. However, I haven't experienced noticeable lag
after this change, and I believe the cost of botline computation would
be much smaller than the cost of decoration providers.
Problem:
Not all Lua code is checked by stylua. Automating code-style is an
important mechanism for reducing time spent on accidental
(non-essential) complexity.
Solution:
- Enable stylua for entire `test/` directory.
- Exclude these high-churn files until this issue is resolved: https://github.com/JohnnyMorganz/StyLua/issues/829
```
test/functional/ui/decorations_spec.lua | 3560 ++++++++++++++++++++++++++++++++++++----------------
test/functional/ui/float_spec.lua | 5826 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------
test/functional/ui/multigrid_spec.lua | 1349 ++++++++++++++------
```
- Make surgical changes to these files (or add `stylua: ignore` in some
small scopes) to improve the result:
```
test/functional/vimscript/msgpack_functions_spec.lua | 1414 +++++++++++++++------
test/functional/api/buffer_spec.lua | 1389 +++++++++++----------
test/functional/api/vim_spec.lua | 2740 +++++++++++++++++++++++-----------------
```
- These "high churn" files are NOT excluded because the changes are
largely an improvement:
```
test/functional/plugin/lsp_spec.lua | 2198 ++++++++++++++++++---------------
test/functional/plugin/shada_spec.lua | 4078 +++++++++++++++++++++++++++++++++++-------------------------
test/functional/ui/cmdline_spec.lua | 1199 +++++++++++-------
test/functional/ui/popupmenu_spec.lua | 1267 +++++++++++--------
test/functional/ui/messages_spec.lua | 1643 +++++++++++++++---------
```
- TODO: how to check "all directories"? With `GLOB_DIRS *` and `/.deps/` (or
`.deps/`) in `.styluaignore`, Lua code in `.deps/` is still checked...
feat(diagnostic): add `vim.diagnostic.count()`
Problem: Getting diagnostic count based on the output of
`vim.diagnostic.get()` might become costly as number of diagnostic
entries grows. This is because it returns a copy of diagnostic cache
entries (so as to not allow users to change them in place).
Getting information about diagnostic count is frequently used in
statusline, so it is important to be as fast as reasonbly possible.
Solution: Add `vim.diagnostic.count()` which computes severity
counts without making copies.
Problem: `functional/vimscript/api_functions_spec` skips a test if the
runtime files are not generated, but this check was broken in a
refactor.
Solution: Since runtime files are now generated for all test targets, do
not skip this test.
There is no reason for this file to be in project root, which is crowded
as is. This also fits nicely part of the ongoing work towards gathering
as much of the documentation as possible into one place.
