As much as I like the guy's overall goal (we need such a solution so bad, really), unfortunately I do have serious concerns with the proposal. Here's a random unorganized dump of my thoughts.

I don't know when the first version of the proposal was created, but libtermkey dates back to 2008. Still I haven't heard about it until a few days ago when someone else posted a request for iterm2. I haven't seen the author driving the change, and without that it's hopeless to get adoption. To get it widespread, IMO he should actively seek for feedback, followed by adoption in several popular terminals and apps.

The proposed change is slightly backwards incompatible, e.g. Ctrl-I, Ctrl-M, Ctrl-[ would send different codes, perhaps a lone Esc as well (details later) or many other keypresses due to the C0->C1 change (you just can't do that, that'd break way too many apps), and also he uses the "sane" value for backspace (^H) as opposed to the currently used "insane" one (^?) (that's a longer story on its own because it has to correlate with the termios settings which the terminal emulator shouldn't just flip as it pleases). Changing the hardwired behavior of terminals would probably break some apps and make users migrate to other terminals. IMO the way to go would be to introduce a new output escape sequence pair that switches to/from this mode, similarly to the app keypad and app cursor key modes (and also the sun/hp/etc function key modes which were recently dropped from g-t but are still present in xterm).

One of the goals is to be able to send Ctrl+Shift+letter combos, but these are often handled by the terminal emulator itself. If it's still important to be able to send it to apps, the proposal should be able to handle other modifiers too (e.g. Cmd on Mac, AltGr; perhaps even report CapsLock and NumLock state??).

The proposal says Shift is not to be encoded as a modifier if it took part in producing the actual character, e.g. turning an "a" into an "A". But what if another modifier has also an effect on the character, e.g. AltGr (many int'l PC layouts), Alt (Mac)? Clarification needed. What about more extreme layouts, e.g. Dvorak that switches to Qwerty when Ctrl is pressed? I'm not entirely convinced that the specs is absolutely clear about it and everyone would interpret it the same way. I might be wrong, though.

Do we want to communicate which key was pressed when multiple keys should produce the same character? E.g. upper row digits vs. numpad digits, separate Home/PgUp/etc vs. numpad versions? Currently the app keypad mode sends different codes for keypad /*-+ characters in one of the numlock states, and the Home/End keys change their escapes on app cursor keys IIRC, often causing them not to work in apps like less, mc, etc. Would we want to keep and further extend these (allowing a carefully written app to distinguish between the two for good causes, yet making it easy to mess up apps and cause faulty behavior) or stay on the safer, yet less informative side? Would the libtermkey library make it easy for apps that are not interested in the details? (I haven't looked at libtermkey.) How would this new mode interfere with app keypad, app cursor, sun/hp/etc function key modes?

Are we really sure it's okay if we don't communicate the Shift, AltGr etc. (whichever actually changed the letter) state for letterlike characters? Won't anyone ever need them and come up with a new proposal or dirty new hacks?

There are layouts where the lowercase and uppercase letters are not on the same key with shift. For historical reasons the keys on the keyboards are labeled as uppercase, and apps ask you to press Ctrl+A whereas it's actually Ctrl+a, or ask you to press Ctrl+Shift+A which is actually Ctrl+Shift+a -- or is it Ctrl+X, where X is the label of the key that produces A when shifted? This probably doesn't occur with English letters, but does with symbols or accented letters. Apps running inside the terminal know nothing about the keyboard layout. Should they show the label Ctrl+# or Ctrl+Shift+3 to the user? With US kbd layout there's no difference; with others there is. On the French keyboard the upper row's key which is labeled "2" in most keyboards produces "é", or "É" if Caps Lock is on, and together with Shift it'll emit the digit 2. So is it Ctrl+Shift+é or Ctrl+Shift+É or 2? How shall an app label its shortcuts and what should be sent in these cases so that it works with all layouts? Back to the previous example. If I were an app developer, I would insist that I decide whether I ask the user to press Ctrl+# or Ctrl+Shift+3 - and no matter what my decision is, I want to be able to recognize that. With US kbd they're the same, with others they're not, and I have no clue which layout the user's using. Yet, I want to be able to tell whether the user pressed Ctrl+# or not; and independently from that, I also want to be able to tell whether the user pressed Ctrl+Shift+3 or not. Does this make any sense or not? I can't see that it's been thought out in the document. I guess X Window and Gnome/KDE/etc. had a couple of attempts until they got it right (well, did they after all?), it would be nice to look at how they handle it.

Marked with (*) in the doc, it says that certain keys produce different sequence depending on the terminals. If we're changing the generated escapes, and we're guarding it with an output escape to enable these, I see no reason to keep this ambiguity, I'd prefer to see either one final fixed sequence, or the design to be explained.

Remember that in the old DOS days the popular Norton Commander changed its bottom row as soon as you pressed the Shift modifier. This is still something that would be cool to have in Midnight Commander. Why don't we send an escape sequence when a modifier is pressed or released? For gaming apps the keyboard repeat rate probably shouldn't matter, they should be interested in when a key is pressed and when it's released. Again, why not send these? At least the doc should provide rationale for the design decisions here if it decides not to become this generic.

What's with non-ASCII letters, e.g. how to encode Ctrl+á? Would the number be according to the current encoding, or Unicode, or (hope not) separate escapes for each byte of UTF-8? If it's always the Unicode value, what should happen when an out-of-charset key is pressed on the keyboard (e.g. "ő" on a Hungarian layout while the terminal runs in Latin-1), would you still transmit its code or not? If yes, would you encode a modifierless "ő" the same way too, denoting by ";1" that no modifier was pressed (kinda resembling to html's &#...; notation for encoding out-of-charset characters), or would you silently swallow the keypress just as it's done now?

The proposal wants to keep the C0 escape byte for the Escape key only and use C1 everywhere else. My vote is a definite big fat no for this. C1 is hardly ever used, in fact gnome-terminal has just recently added support (for the sequences emitted by the apps; not for the keyboard codes) because after having g-t for like 10 years, one guy reported that he missed this feature. C1 has severe problems with Unicode.

xterm-319 just added a section to its ctlseqs explaining that C1 means the 0x9B byte regardless of encoding, rather than U+009B encoded in UTF-8. I'm not sure I understand why, but allegedly this is what the standard says, and is clearly so broken that noone implements in UTF-8 mode. Some emulators recognize U+009B encoded in UTF-8, it's a more reasonable technical approach, xterm deliberately doesn't because it's not what the standard says. The proposal goes for the single byte C1 approach, and says it's fine because no UTF-8 character begins with 0x9B. This forgets about two issues. One is that it'd cause problems with layers that perform charset conversion, e.g. luit, screen or tmux with different inner and outer charsets, just as the legacy mouse protocol had severe issues here since the whole stream isn't valid UTF-8 anymore. The other is that UTF-8 has the nice property that it can detect any invalid character and resynchronize immediately; if you allow a single C1 byte with its own meaning then it's no longer true. An incomplete UTF-8 (okay it's unlikely to happen since we're talking about the keyboard, but still: if your terminal is configured to some 8-bit charset, yet your app expects UTF-8, you might by a single keypress generate the first byte of a UTF-8), followed by the 0x9B that's supposed to start an escape sequence forms a complete (and absolutely irrelevant) Unicode character and swallows your C1. It's not that big of a deal since such setups are misconfigured anyway, but still, it's ugly as hell (and would be outright broken if we were talking about the escapes that are generated by apps).

In my opinion C1 shouldn't be considered as a possibility at all. Since we're breaking compatibility and would need to explicitly enable the new keys with escape sequences anyway, emitting two 0x1B bytes for the Escape key is I believe a reasonable choice instead. Note that this would prevent expert users from manually entering escape sequences, e.g. to quit Midnight Commander with Esc 0 when F10 is misconfigured to open the terminal's menu.

Future extensibility: see http://www.midnight-commander.org/ticket/3136. There needs to be some means by which the current libtermkey implementation already knows the pattern future escape sequences will follow. It's okay to discard them (what else could it do?) but at least it has to know for sure where those escapes end.

But back to what I said at the beginning: The biggest problem is that the author doesn't drive the adoption of this feature, and without that, it won't go anywhere. I'd be happy to add this feature if the technical problems are sorted out and if I see that it'll become widely adopted in a few years, but that requires that the author (or someone else) knocks on the door and gets buy-in from quite some terminal emulators and popular apps as well.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2217.