Rework-of: ea7491586f
Helped-by: Björn Linse <bjorn.linse@gmail.com>
- The old (Vim) use of (char_u **)"" before ea7491586f is garbage,
which hints that this value was never used.
- The necessary condition is next to the NULL assigmnent, the pointer
would only be started to be accessed, if the length assignment next to
it is also changed.
Problem: Cannot act on edits in the command line.
Solution: Add the CmdlineChanged autocommand event. (xtal8, closesvim/vim#2603,
closesvim/vim#2524)
153b704e20
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: One character cmdline abbreviation not triggered after '<,'>.
Solution: Skip over the special range. (Christian Brabandt, closesvim/vim#2320)
5e3423d192
- Checks for ECHOE, ICANON were left over from Vim code. We already
reference the symbols elsewhere without checking.
- newline_on_exit, intr_char: Both are vestigial remnants of Vim 4.x,
not implemented in Nvim. intr_char is a termios/stty feature, it's
probably not useful because users have other ways to configure their
terminals.
Make sure cmdline updates will receive highlight specifications the same
way as screen cells. This is controlled by the ext_newgrid option so
nothing is changed by default (as screen cells are also not changed by
default). This was already done for the cmdline itself in #8221, this
extends it to cmdline_block. Which currently doesn't store highlights,
but the placeholder should be one that makes sense for future use.
