diff options
| author | wm4 <wm4@nowhere> | 2020-09-17 15:31:19 +0200 |
|---|---|---|
| committer | wm4 <wm4@nowhere> | 2020-09-17 15:31:19 +0200 |
| commit | 602384348e718c772a2f0d1490d0f26d3578c373 (patch) | |
| tree | 469226b58b9178846063e2d1ee430322daf9fb7c /demux | |
| parent | 76fb001c4208bcb9d235d2e8e920f419ad844dd5 (diff) | |
| download | mpv-602384348e718c772a2f0d1490d0f26d3578c373.tar.bz2 mpv-602384348e718c772a2f0d1490d0f26d3578c373.tar.xz | |
terminal: attempt to handle the ESC key
Due to Unix being legacy garbage, it's not possible to safely detect the
ESC key on terminal. The key sequences are ambiguous. The code for the
ESC key also starts the sequences for other special keys.
Until now, you needed to hit ESC twice for it to be recognized.
Attempt to handle this better by using a timeout to detect the key. If
ESC is in the input buffer, but nothing else arrived after a timeout,
assume it's the ESC key. I think this is the method vim uses. Currently,
the timeout is set at 100ms. This is hardcoded and cannot be changed.
It's possible that this causes problems on slow ssh connections or so.
I'm not sure what exactly happens if you manage to get ESC + another
normal key into the input buffer. If it's a known sequence, it will be
matched and interpreted as such. If not, it'll probably be discarded.
Diffstat (limited to 'demux')
0 files changed, 0 insertions, 0 deletions