Why?
- Because we can.
- Because the TUI is just another GUI™
- Because it looks kinda nice, and provides useful context like 1 out of 100
times
Complies with "don't pay for what you don't use".
Some crashes for resizing were unfolded, add tests for those.
By historical accident, Nvim defaults to background=light. So on a dark
background, `:colorscheme default` looks completely wrong.
The "smart" logic that Vim uses is confusing for anyone who uses Vim on
multiple platforms, so rather than mimic that, pick the (hopefully) most
common default.
- Since Neovim is dark-powered, we assume most users have dark backgrounds.
- Most of the GUIs tend to have a dark background by default.
ref #6289
NB: existing `color default` test was actually enough to trigger the bug,
when ext_newgrid=false is used. I created the `:hi Normal` test as
I thought the builtin colors wouldn't set Normal (unless 'bg' is changed)
But as the root cause actually comes from `:hi Normal`, it makes sense
to still add the separate test (if `color default` here gets optimized to
become a no-op, or something).
Add ext_newgrid and ext_hlstate extensions. These use predefined
highlights and line-segment based updates, for efficiency and
simplicity.. The ext_hlstate extension in addition allows semantic
identification of builtin and syntax highlights.
Reimplement the old char-based updates in the remote UI layer, for
compatibility. For the moment, this is still the default. The bulitin
TUI uses the new line-based protocol.
cmdline uses curwin cursor position when ext_cmdline is active.
Make HlAttr contain highlighting state for both color modes (cterm and rgb).
This allows us to implement termguicolors completely in the TUI.
Simplify some logic duplicated between ui.c and screen.c. Also avoid
some superfluous highlighting reset events.
- Use this to properly test cursor shape events.
- tests: update screen_basic_spec to use `screen:expect` short form.
Clearer than using `screen:wait` directy.
`find_command(s->ca.cmdchar) >= 0` was established near the start of
normal_execute(). And `unshift_special(&s->ca);` "should" not ever
result in s->ca.cmdchar containing a multibyte char.
So only an assert() is needed here.
Also give NVIM_TUI_ENABLE_CURSOR_SHAPE more granularity:
0 = do not change cursor shape
1 = non-blinking ("steady") cursor with mode-sensitive shape
2 = blinking cursor with mode-sensitive shape
Note: blink state is not changed for Konsole, instead user's terminal
preference makes the decision. (Can't do that for xterm-likes, DECSCUSR
forces us to choose blink-state.)
This is a temporary step until the TUI respects 'guicursor'
Ref: https://github.com/neovim/neovim/issues/2583#issuecomment-272988384
When there is a difference in expected vs. actual row count, the user
gets a confusing message about being unable to string concat a nil value
from screen:expect.
This assert makes it clear what the problem is rather than requiring
people to dig through the code of screen:expect to determine what
happened.
Periodically skip :! spam. This is a "cheat" that works for all UIs and greatly
improves responsiveness when :! spams MB or GB of output:
:!yes
:!while true; do date; done
:!git grep ''
:grep -r '' *
After ~10KB of data is seen from a single :! invocation, output will be skipped
for ~1s and three dots "..." will pulse in the bottom-left. Thereafter the
behavior alternates at every:
* 10KB received
* ~1s throttled
This also avoids out-of-memory which could happen with large :! outputs.
Note: This commit does not change the behavior of execute(':!foo').
execute(':!foo') returns the string ':!foo^M', it captures *only* Vim
messages, *not* shell command output. Vim behaves the same way.
Use system('foo') for capturing shell command output.
Closes#1234
Helped-by: oni-link <knil.ino@gmail.com>
