Avoid clearing the screen in most situations. NOT_VALID should be
equivalent to CLEAR unless some external force messed up the terminal,
for these situations <c-l> and :mode will still clear the screen.
Also eliminate some obsolete code in screen.c, that dealt with that in
vim drawing window 1 can mess up window 2, but this never happens in
nvim.
But what about slow terminals? There is two common meanings in which
a terminal is said to be "slow":
Most commonly (and in the sense of vim:s nottyfast) it means low
bandwidth for sending bytes from nvim to the terminal. If the screen is
very similar before and after the update_screen(CLEAR) this change
should reduce bandwidth. If the screen is quite different, but there is
no new regions of contiguous whitespace, clearing doesn't reduce
bandwidth significantly. If the new screen contains a lot of whitespace,
it will depend of if vsplits are used or not: as long as there is no
vsplits, ce is used to cheaply clear the rest of the line, so
full-screen clear is not needed to reduce bandwith. However a left
vsplit currently needs to be padded with whitespace all the way to the
separator. It is possible ec (clear N chars) can be used to reduce
bandwidth here if this is a problem. (All of this assumes that one
doesn't set Normal guibg=... on a non-BCE terminal, if you do you are
doomed regardless of this change).
Slow can also mean that drawing pixels on the screen is slow. E-ink
screens is a recent example. Avoiding clearing and redrawing the
unchanged part of the screen will always improve performance in these
cases.
Problem: Cursorline not removed when using 'cursorbind'. (Justin Keyes)
Solution: Store the last cursor line per window. (closesvim/vim#3488)
4a5abbd613
closes#7383closes#7715
This implements the compromise described in #7383:
* low-priority CursorLine if foreground is not set
* high-priority ("same as Vim" priority) CursorLine if foreground is set
ref d1874ab282
ref 56eda2aa17
Since "builtin" terminfo definitions were implemented (7cbf52db1b),
the decisions made by tui.c and terminfo.c are more relevant. Exposing
that decision in the 'term' option helps with troubleshooting.
Also: remove code that allowed setting t_Co. `:set t_Co=…` has never
worked; the highlight_spec test asserting that nvim_set_option('t_Co')
_does_ work makes no sense, and should not have worked.
Hope this will make people using feed_command less likely: this hides bugs.
Already found at least two:
1. msgpackparse() will show internal error: hash_add() in case of duplicate
keys, though it will still work correctly. Currently silenced.
2. ttimeoutlen was spelled incorrectly, resulting in option not being set when
expected. Test was still functioning somehow though. Currently fixed.
It is otherwise impossible to determine which test failed sanitizer/valgrind
check. test/functional/helpers.lua module return was changed so that tests which
do not provide after_each function to get new check will automatically fail.
Problem: When "syntax manual" was used switching between buffers removes
the highlighting.
Solution: Set the syntax option without changing the value. (Anton
Lindqvist)
885f24fbca
Patch applied cleanly to the nvim sources except for version.c.
Plugins (YCM, dispatch.vim) use gui_running to decide behavior; so do
some colorschemes. Up to now, nvim lied about gui_running for the
benefit of colorschemes and the detriment of all _other_ plugins that
check this condition. That's counterproductive: a user employs at most
_one_ colorscheme but may use many other plugins which expect the Vim
legacy semantics of gui_running.
Moreover, colorschemes usually don't _need_ to check gui_running: they
can instead set cterm{fg,bg} and gui{fg,bg} in the same :highlight call.
It is reasonable for users who want "true color" to modify their
colorscheme once (or request upstream to do so) in order to avoid
running into quirks in any other plugins.
Closes#2782
