Add tests for:
- Cursor position restored after :map expr
- Cursor position restored after :imap expr
- Error in :cmap expr handled correctly
Cherry-picked from #12837
Problem: When user tries to exit with CTRL-C message is confusing.
Solution: Only mention ":qa!" when there is a changed buffer. (closesvim/vim#4163)
a84a3dd663
vim-patch:8.1.1052: test for CTRL-C message sometimes fails
Problem: test for CTRL-C message sometimes fails
Solution: Make sure there are no changed buffers.
553e5a5c56
vim-patch:8.1.1053: warning for missing return statement
Problem: Warning for missing return statement. (Dominique Pelle)
Solution: Add return statement.
d6c3f1fa2b
vim-patch:8.0.0714: when a timer causes a command line redraw " goes missing
Problem: When a timer causes a command line redraw the " that is displayed
for CTRL-R goes missing.
Solution: Remember an extra character to display.
a92522fbf3
vim-patch:8.0.0720: unfinished mapping not displayed when running timer
Problem: Unfinished mapping not displayed when running timer.
Solution: Also use the extra_char while waiting for a mapping and digraph.
(closesvim/vim#1844)
6a77d2667eclose#9835
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: For some people the hint about quitting is not sufficient.
Solution: Put <Enter> separately. Also use ":qa!" to get out even when
there are changes.
28a8193e31
Implement nvim_command_output with `execute({cmd},"silent")`.
Behavior changes:
- does not provoke any hit-enter prompt
- no longer prepends a newline char
- does not capture some noise (like the "[New File]" message, see the
change to tabnewentered_spec.lua)
Technically ("bug-for-bug") this a breaking change. But the previous
behavior of nvim_command_output meant that it probably wasn't used for
anything outside of tests.
Also remove the undocumented `v:command_output` variable which was
a hack introduced only for the purposes of nvim_command_output.
closes#7726
The issue with debug mode was actually not cleaning up after `try_enter`:
location `&tstate` was pointing to got invalidated and received some “garbage”
(actually, values that got stored on the stack afterwards). But pointer to that
garbage was still stored in `msg_list`, so next attempt to check it resulted in
a crash.
Problem: when processing cycle such as
:for pat in [' \ze*', ' \zs*']
: try
: let l = matchlist('x x', pat)
: $put ='E888 NOT detected for ' . pat
: catch
: $put ='E888 detected for ' . pat
: endtry
:endfor
`:let l = …` throwing an error causes this error to be caught after
color_cmdline attempts to get callback for highlighting next line (the one with
`$put = 'E888 NOT…`). Saving/restoring state prevents this from happening.
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.
