Korona wrote:
The question was about vim: As there is no way to distinguish a fast enough ESC+x from an escape sequence vim indeed uses timing information to figure this out. That is documented and there are options to control it: esckeys, timeout, timeoutlen.
This is concise answer to most of the original question. There was also a sub-question however, and I am interested to know as well:
lovelyshell wrote:
I don't know how vim avoids such problem, and do you have a better approach?
And then the discussion carried on to network congestion effects interacting with ssh, etc.
From Korona's clarification and what we know, I think it is safe to say that console applications accessing terminal character devices are not supposed to think of the keyboard as their input. They can apply heuristics like vim, but IIUC, the reliable behavior is to think of the pseudo-terminal device as a classic terminal that somehow gets emulated using the modern hardware. (P.S. In that sense, the <Esc> key can be considered a key specifically intended for escape sequences.)
Apparently there are two ways to deal with the keyboard in a precise way. One is to read the input device in devfs (as demonstrated by the code linked
here), and the other is to create an x-window client (which uses the same approach, but does not require root privileges.)
Edit: Obviously, you wouldn't want to deploy x apps everywhere, but the alternatives are to demand root privileges, or use a timing heuristics on the terminal device. (The last may be the conventional technique for simple TUI-style apps, but I think is pretty much a hack.)