Customizing sequences sent by keys

[CyberShadow]

Hi @gnunn1!

I'm currently working on term-keys, an Emacs package which allows lossless keyboard input with Emacs' terminal interface and supported terminal emulators.

Some terminals allow customizing what byte sequences a key + modifier combination sends, which is a feature term-keys uses to achieve its goal. For example, urxvt and xterm allow doing so via the command-line or X resources, and Konsole even has an UI for it:

My current understanding is that this is not a feature that Tilix currently has, or any GNOME VTE-based terminal. Is that correct? Do you know if this is an intrinsic limitation of the VTE widget? If not, would this be something that might be added to Tilix in the future? Thanks!

[gnunn1]

VTE has a feed method to send arbitrary sequences to it. Having said that, I don't have any plans to implement this however I'm not opposed to accepting a PR for it. However this needs to be tied into the existing shortcut preferences in some way so there is a logical and consistent way to set shortcuts. I wouldn't want to see two interfaces, one for setting shortcuts for actions and one for this.

[egmontkob]

VTE indeed doesn't support customizing the escape sequences. However, as gnunn1 said, it's possible for Tilix to grab the keypresses and feed arbitrary byte sequences to VTE, rather than the actual keypress. But then this should be implemented in about a dozen VTE-based apps rather than once in VTE, which isn't a neat idea.

I personally don't like the approach shown in the screenshot at all. I admit it's ridiculous that certain key combos can't be distinguished, but it's also ridiculous if the user ever needs to manually configure the behavior and enter magic escape sequences in hex or anything like this to get it working. That's just so last century, and I hate that for some reason terminal emulators cannot catch up with the 21st century's basic usability requirements.

The proper approach would be to have an escape sequence which switches the terminal emulator to a different mode. Actually, there is one in xterm called modifyOtherKeys, see e.g. VTE bugs 477068 and 730157 for a few thoughts about them. The point is that the user shouldn't have to configure anything at all, it should Just Work™.

By the way, as per these bugs, emacs already seems to support this mode, so I don't see the rationale for your term-keys project. I didn't take a look at the details and I'm not an emacs user, so obviously I must be missing proper insight.

[CyberShadow]

but it's also ridiculous if the user ever needs to manually configure the behavior and enter magic escape sequences in hex or anything like this to get it working

Agreed; still, it seems like it's a feature required by certain use cases.

That's just so last century, and I hate that for some reason terminal emulators cannot catch up with the 21st century's basic usability requirements.

The problem is that there is no established consensus on a way to encode every key combination that can be typed in a terminal emulator from a PC keyboard.

By the way, as per these bugs, emacs already seems to support this mode, so I don't see the rationale for your term-keys project.

I wasn't aware of modifyOtherKeys, however it seems like it still offers only a subset of what's possible with term-keys. It also enables terminals which do not support modifyOtherKeys directly.

[egmontkob]

The problem is that there is no established consensus on a way to encode every key combination that can be typed in a terminal emulator from a PC keyboard.

It is a truly hard problem to design the proper solution. When to rely on the keyboard layout to "resolve" the value, and when to transfer the modifier and the... the what, the modifier-less code, or the physical keycode, or what exactly?

E.g. with standard US layout one presses Shift + 'a', would you somehow encode Shift and lowercase 'a', or instead uppercase 'A'? Would it be emacs's job to turn the letter to uppercase? How to encode the state of Caps Lock?

What to do with weird layouts, such as the French one when what's usually the digit 2 is actually the letter 'é', whereas together with Shift it becomes the digit 2 and not uppercase 'É' (I think you have to use Caps Lock for that). If you press it with Shift, is the terminal emulator still supposed to simply send the digit 2, without any modifiers, right? Or Shift + 2, which emacs will convert to... to what? Or Shift + 'é', which it might erroneously convert to 'É', as with other layouts (e.g. Hungarian) that's the right thing?

Would you want emacs to be able to tell Space from Shift + Space? I, for one, would hate if they had any chance of being different, since that would break typing some all uppercase text with spaces in between by holding down Shift. Others might find a valid use case for that.

There's two contradicting requirements: One is to know exactly what keys and modifiers are pressed (possibly even including situations like a modifier only; might be useful e.g. for Midnight Commander to know when Shift is pressed to alter its bottom button bar), and the other requirement is to send only the resolved symbol according to the keyboard layout and deliberately hide which physical key generated that symbol. The former is typically useful for games and alike (e.g. holding down Shift makes you go faster), whereas the latter is for getting actual work done. Yet here we'd need some bits of the former for increased work productivity.