You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Why doesn't it currently? Currently, there are a number of classes of physically-distinct key presses that terminals encode using the same bytes.
Special names for some ASCII characters collide with Ctrl-modified letters. For example, Tab is Ctrl-I.
The Ctrl modifier encodes lower or upper-case letters identically; Ctrl-I is Ctrl-Shift-I.
UTF-8 collides with 8bit-high characters; e.g. Alt-C might be encoded as 0xc3, which is the first UTF-8 byte of many Unicode characters, such as é.
Sometimes programs rely on timing information to distinguish, for example, Alt-C from the two separate keypresses of Escape followed by C. This results in delays to recognise a plain Escape key if the time is too long, or erroneously recognising Escape followed by a letter as an Alt-modified letter if typed too quickly, or if the time limit is too short.
Even when keys produce unique unambiguous byte sequences, it may be that some programs cannot recognise them.
The way terminals encode modified keypresses is an extension to the original methods used in the 1970s, and some older code cannot parse them correctly. Press Ctrl-Up on a modern xterm and watch a program fail and die in all sorts of interesting ways because they don't have real CSI parsers.
How can we fix this?
By having a sane and sensible model on BOTH ends of the terminal interaction, and a well-defined way of communicating. How exactly we go about this really depends who you are:
Making a terminal send the correct key encodings should be a relatively easy task, given the encoding scheme already splits modifiers and keysyms in a way likely to be similar to the underlying input system at work, such as X11 or Win32.
All of our Keyboard Input routines are handled by vte. Your suggestion is best taken up with them. As a bonus, that will fix it on multiple terminal emulators, such as Tilix, gnome-terminal, and xfce4-terminal
Why doesn't it currently? Currently, there are a number of classes of physically-distinct key presses that terminals encode using the same bytes.
Special names for some ASCII characters collide with Ctrl-modified letters. For example, Tab is Ctrl-I.
The Ctrl modifier encodes lower or upper-case letters identically; Ctrl-I is Ctrl-Shift-I.
UTF-8 collides with 8bit-high characters; e.g. Alt-C might be encoded as 0xc3, which is the first UTF-8 byte of many Unicode characters, such as é.
Sometimes programs rely on timing information to distinguish, for example, Alt-C from the two separate keypresses of Escape followed by C. This results in delays to recognise a plain Escape key if the time is too long, or erroneously recognising Escape followed by a letter as an Alt-modified letter if typed too quickly, or if the time limit is too short.
Even when keys produce unique unambiguous byte sequences, it may be that some programs cannot recognise them.
How can we fix this?
By having a sane and sensible model on BOTH ends of the terminal interaction, and a well-defined way of communicating. How exactly we go about this really depends who you are:
Making a terminal send the correct key encodings should be a relatively easy task, given the encoding scheme already splits modifiers and keysyms in a way likely to be similar to the underlying input system at work, such as X11 or Win32.
http://www.leonerd.org.uk/hacks/fixterms/
The text was updated successfully, but these errors were encountered: