When we see an unknown sequence, it is not enough
to drop already received part - there can be more of it
coming over e.g. a serial line.
To prevent interpreting it as a random garbage,
eat and discard all chars that follow.
Small, but non-zero timeout is needed to reconnect
escape sequence split
Figuring out what exactly happens in get_key_code() when user
uses various function keys is not trivial.
While working on some fixes, I added a debugging code
which records a log in /tmp/mc_key.log; I would like
to save future developers from doing this again.
This patch adds my debugging code, di
With the recently rearranged code, it's easy to see that "this == NULL"
can't be true here:
note -> if (!this->child)
{ ...
return correct_key_code (code);
}
if (!push_char (c))
{ ...
goto pend_send;
This change prevents misinterpreting an unknown ESC sequence's
tail as a garbage input. To reproduce, run "sleep 3" and
hold down Down_Arrow key until sleep runs.
With debugging log enabled, the following can be seen:
entered get_key_code(no_delay:0)
c=tty_lowlevel_getch()=27
push_char(27) !0
c
This change slightly simplifies and rearranges the code
in get_key_code(), reduces indentation levels there,
adds a few comments. The logic remains the same.
This is a preparatory patch for subsequent changes.
Signed-off-by: Denys Vlasenko
---
lib/tty/key.c | 126 --
I got tired of seeing garbage when I press function key MC doesn't know.
This changeset attempts to eradicate this problem.
Denys Vlasenko (5):
keyboard input: simplify code, no logic changes
keyboard input: add commented-out debugging logging mechanism.
keyboard input: remove unreachable co
