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.
clang scan-build noticed that find_command() may bitmask `eap->flags`.
cmd_can_preview() only uses `ea.cmdidx`, but let's fix the warning...
Found by clang scan-build 5.0
Problem: Weird autocmd may cause arglist to be changed recursively.
Solution: Prevent recursively changing the argument list. (Christian
Brabandt, closesvim/vim#2472)
9e33efd152
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.
Problem: Vim becomes unusable after opening new window in BufWritePre
event.
Solution: Call not_exiting(). (Martin Tournoij, closesvim/vim#2205)
Also for "2q" when a help window is open. Add a test.
2c33d7bb69
Problem: Completion for user names does not work if a prefix is also a full
matching name. (Nazri Ramliy)
Solution: Accept both full and partial matches. (Dominique Pelle)
6c5d104302
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.
Problem: Swap file exists briefly when opening the command window.
Solution: Set the noswapfile command modifier before splitting the window.
(James McCoy, closesvim/vim#1620)
3bab93998d
This changes Ex mode (Q, -e) to work like Vim's "improved Ex mode"
(gQ, -E). That brings some small behavior differences, but should not
impact most Ex scripts (unless, for example, they depend on mappings
being disabled--but that can be solved for -e by skipping user config).
Before this change:
* the screen test hangs.
After this change:
* Q acts like gQ.
* -e/-es differs from -E/-Es only in its treatment of stdin.
This moves towards potentially removing getexmodeline().
(HINT: That does NOT mean "removing Ex mode", it means removing the
Vi-compatible Ex mode, which differs from Vim's "improved Ex mode" only
in some minor details (e.g. mappings are disabled).)
ref #1089 :-)~
Problem: ml_get errors in silent Ex mode. (Dominique Pelle)
Solution: Clear valid flags when setting the cursor. Set the topline when
not in full screen mode.
d5d37537d1
