Problem: Expression evaluation may repeat an error message. (Jason
Franklin)
Solution: Increment did_emsg and check for the value when giving an error
for the echo command.
76a6345433
- TUI: _never_ rely on BCE for implicit clearing, only explicit commands.
- TUI: use unibi_erase_chars when possible.
- TUI: use end-exclusive ranges for invalid and cleared areas
- screen: scrolling leaves scrolled in aree undefined. This is a
conservative change, a client assuming the old semantics will still
behave correctly.
- screen: factor out vsep handling from line drawing. This is needed
anyway for the multigrid refactor.
- screen: simplifications of win_do_lines
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.
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: After aborting an Ex command g< does not work. (Marcin
Szamotulski)
Solution: Postpone clearing scrollback messages to until the command line
has been entered. Also fix that the screen isn't redrawn if after
g< the command line is cancelled.
f2405ed232
Problem: Using a function pointer instead of the actual function, which we
know.
Solution: Change mb_ functions to utf_ functions when already checked for
Unicode. (Dominique Pelle, closesvim/vim#1582)
ace95989ed
Since `c` there is a result of evaluating `TO_SPECIAL` macros it may be only one
of the following three things:
1. K_SPECIAL
2. K_ZERO (note: not KS_ZERO)
3. negative integer resulting from evaluating TERMCAP2KEY macro.
All variants here are negative and thus fail next !IS_SPECIAL(c) check (negative
is special). If `c` was really NUL it would fall into the `!IS_SPECIAL(c)` block
and use whatever character is third in `<80>{a}{b}` combo. For `<Nul>` it is
X (`<80><ff>X`).
Problem: When in Ex mode and an error is caught by try-catch, Vim still
exits with a non-zero exit code.
Solution: Don't set ex_exitval when inside a try-catch. (partly by Christian
Brabandt)
2b7bc567b9
Problem: Cannot make Vim fail on an internal error.
Solution: Add IEMSG() and IEMSG2(). (Domenique Pelle) Avoid reporting an
internal error without mentioning where.
95f096030e
Signed-off-by: Michael Schupikov <michael@schupikov.de>
This also attempted to fix problem with cancelling input() on error by avoiding
standard error printing facilities (assumed thrown error message is the
problem), but with no luck so far.
