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.
The statusline may incorporate b:term_title, so redraw it when that
title changes.
Introduce a new function status_redraw_buf to redraw windows associated
with the current buffer.
Vim :! may "mess up the screen" because of e.g. switching between cooked
mode, but Nvim just uses pipes. So maybe we can avoid these
redraw_later_clear() CYA calls.
Previously, when neovim would wrap a line across multiple lines,
terminal emulators could not detect that the lines represent a single
wrapped line as opposed to several separate lines. As a result, many
terminals' selection/copying functionality would treat a wrapped line as
several newline-delimited lines.
Fix this by reenabling a "special trick" from Vim. When a line is
wrapped, write the last character of that line followed by the first
character of the next line to the terminal. This hints to the terminal
that the next line is a continuation of the current line.
Extends the raw_line event with a "wrap" parameter which controls when
to do wrap hinting.
Problem: Accessing freed memory when EXITFREE is set and there is more than
one tab and window. (Dominique Pelle)
Solution: Free options later. Skip redraw when exiting.
4f1982800f
Problem: Bogus characters appear when indenting kicks in while doing a
visual-block append.
Solution: Recompute when indenting is done. (Christian Brabandt)
e2e69e4813
Problem: Popup menu displayed wrong when using autocmd.
Solution: Use aucmd_prepbuf(). Force updating status line if the popup menu
is going to be redrawn anyway. (Christian Brabandt, closesvim/vim#3009)
6ba3ec1bac
Problem: When making a vertical split the mode message isn't always
updated, "VISUAL" remains. (Alexei Averchenko)
Solution: Only reset clear_cmdline when filling all columns of the last
screen line. (Tom M. closesvim/vim#2611)
5bab555c2f
Problem: wrong highlighting with combination of match and 'cursorline'.
Solution: Use "line_attr" when appropriate. (Ozaki Kiichi, closesvim/vim#2111)
But don't highlight more than one character.
0aa398f55a
Problem: Signs can be drawn on top of console messages.
Solution: don't redraw at a prompt or when scrolled up. (Christian Brabandt,
closesvim/vim#1907)
0792048842
