When an unknown key is pressed, it is interpreted as garbage. It's better to interpret such keys as "nothing was pressed"

[vda]

For example, Ctrl-Alt-Shift-Right_Arrow acts as if I pressed "1;8C" keys.

We need to ignore ALL bytes, not just a few of them, if we saw ESC byte, then, in rapid succession, some bytes which do not constitute a known key.

Patches were sent to ML with subject line "keyboard input: stop generating garbage input from unknown ESC sequences"

[slavazanko]

Hi Denys,

As i see, first patch in your patch-set is ​https://mail.gnome.org/archives/mc-devel/2012-October/msg00004.html

Is the patch is empty or something is wrong?

Thanks.

[vda]

Is the patch is empty or something is wrong?

No, nothing is wrong.
"[PATCH 0/nnn]" email is used to precede a patch set with an overall explanation what entire set achieves (as opposed to per-patch comments which explain what each individual patch is doing).
"[PATCH 0/nnn]" email does not contain any patches. They start from "[PATCH 1/nnn]".

[slavazanko]

Created branch 2988_ignore_unknown_esc_sequences

Initial changeset:0552611557e9835eccdf40b7b5b66bf04b6b8bf1

Review, please.

[slavazanko]

MC produces garbage when we will press ESC and next Home or End key
For example, Esc,Home produces:

OH

[slavazanko]

Merged to master: [1df77c409e9fca7fe93236ddd183948b5a699471]

git log --pretty=oneline f09b319..664e7d3

[slavazanko]

​http://www.midnight-commander.org/wiki/NEWS-4.8.9?action=diff&version=5

[egmont]

Please see #3136 for followup.

[vda]

Patch has been changed a bit: "discard garbage" bit of code was

                    int paranoia = 20;
                    while (getch_with_timeout (50*1000) >= 0 && --paranoia != 0)
                        continue;

in my patch, but in mc-4.8.11 it is

                    int paranoia = 20;
                    while (getch_with_timeout (old_esc_mode_timeout) >= 0 && --paranoia != 0)
                        ;

This is wrong. The timeout value here controls how many microseconds mc waits to eat every next "bogus char". It must be big enough to work on serial lines, where it looks like this:

ESC ...<a few ms>... CH1 ...<a few ms>... CH2 ...<a few ms>...<nothing>

therefore I picked 50 ms as it should work even on stone-age ~1000 baud serial lines; yet, it must not be too big!
Else, a human pressing bogus key and then, relatively swiftly, pressing a valid key is:

ESC CH1 CH2 ...<quarter second of confusion>... VALID_CHAR

The code in 4.8.11 will eat VALID_CHAR too, because it is within old_esc_mode_timeout (1 second by default).

This what caused ticket 3136 to be created...

[ossi]

the idea to use old_esc_mode_timeout was based on the assumption that it would be configured correctly for the expected maximal line delay between adjacent packets (which may be a lot longer than 50ms). if one configures it for the latency of a human pressing esc, the delay becomes unreasonably long for "real" sequences, but there is little that can be done about that from the timing side. the idea of "resetting" sequences when the next esc is received seems reasonable (i wouldn't make assumptions about any other characters).

[vda]

the idea to use old_esc_mode_timeout was based on the assumption that it would be configured correctly for the expected maximal line delay between adjacent packets (which may be a lot longer than 50ms).

I have doubts there are non-degenerate cases where bytes from a single key sequence end up being split across e.g. ssh packets.

How about changing default value of old_esc_mode_timeout to a less paranoidally large value of 1000 ms? e.g. to 100 ms?