When we get an ESC from the keyboard, it might be the start of an
escape sequence, but the keyboard routines will need a little time
(tens of microseconds, probably) to get these codes to ncurses.
So, when doing verbatim input, pause a moment after an ESC.
This completes the fix for https://savannah.gnu.org/bugs/?58909.
Always interpret ESC followed by BS or DEL as <Alt+Backspace>.
This fixes https://savannah.gnu.org/bugs/?58910.
Bug existed since commit 40b03162 from one week ago,
since M-Bsp was hard-bound to deleting a word backwards.
(This could lead to unwanted behavior when the user wants to enter
a literal escape character (0x1B) while the input is somehow getting
stalled, because then a command keystroke after the M-V <Esc> would
get inserted verbatim too, instead of getting acted upon. But that
is a small price to pay for getting the correct behavior for both
M-V M-Bsp and M-V M-Enter.)
This fixes https://savannah.gnu.org/bugs/?58909.
Bug existed since version 2.6.3, commit 08c51cfd,
but also occurred erratically beforehand.
It jars a bit that it is <Ctrl+Delete> that deletes a word rightward
and <Alt+Backspace> that deletes a word leftward. But it's good to
also have a two-key keystroke bound by default to 'chopwordleft',
and not just the three-key <Ctrl+Shift+Delete>.
This fulfills https://savannah.gnu.org/bugs/?58709.
Requested-by: Axel Scheepers <axel.scheepers76+gnu@gmail.com>
The whiles are unneeded because the result of get_input() can
never be NULL when in waiting mode -- and only when searching
for something are we NOT in waiting mode.
<Ctrl+numeric slash> does not invoke Go To Line, so it is fitting
that <Esc> <Esc> <numeric slash> does neither. If some user does
want the double escape plus slash to work, they can use --raw.
(Also, if someone really uses <Esc> <Esc> <numeric slash>, they
probably also type the desired line number on the numeric keypad,
and for that to work they needed to have NumLock engaged, and in
that case the double escape plus slash will work fine.)
(Getting rid of this numeric-slash support makes the three-escapes
case very similar to the one-escape case, allowing the first to be
folded into the latter in the next commit.)
With the two situations that need to preserve the escape counter
now returning directly, the resetting of this counter can happen
at the end of each case block.
The escape-parsing routine nowadays returns FOREIGN_SEQUENCE instead
of ERR when encountering an unknown sequence. So, with the two cases
that demand ERR now handled directly, there is no need to check for
ERR any more.
There is no need to reset the digit counter (because this counter
matters only when the escape counter equals two) -- resetting the
escape counter is enough.
The digit counter will be reset to zero the next time when <Esc>
is pressed, and the byte holder gets re-initialized when the next
first digit is pressed. And the escape counter is reset to zero
after returning from a result-giving call of get_byte_kbinput().
When get_byte_kbinput() is called, it has already been determined that
the keyboard input is a digit from zero to nine (or from zero to two
for the first digit), so there is no need to check this again.
When <Esc><Esc> is followed by digit 0 or 1 or 2 but then NOT two more
digits follow, then both the escape counter and the digit counter should
start afresh when a new ESC code arrives.
This fixes https://savannah.gnu.org/bugs/?58788.
Bug existed since before version 2.0.6.
Also, remove an unneeded 'if', as parse_escape_sequence() is only
ever called when there are at least two bytes after the Esc code.
(If there were not, the 'for' loop after calling convert_sequence()
would use an uninitialized 'consumed' value.)
Benno Schulenberg