Shift does not alter input produced by [Control-]BackSpace #734

Closed
opened 4 months ago by feeptr · 3 comments
feeptr commented 4 months ago

As far as I can tell, BackSpace and Shift-BackSpace produce the same input (^?) and cannot be differentiated by programs running in the terminal. The same is true of Control-BackSpace and Control-Shift-BackSpace (which produce ^H). Could foot provide some way of making these key sequences produce different inputs which programs running in the terminal could distinguish?

Arrow keys and the Delete key, for example, produce different input sequences in all these cases.

This could plausibly be solved as part of #325, but doesn't strictly require customizability.

As far as I can tell, BackSpace and Shift-BackSpace produce the same input (`^?`) and cannot be differentiated by programs running in the terminal. The same is true of Control-BackSpace and Control-Shift-BackSpace (which produce `^H`). Could foot provide some way of making these key sequences produce different inputs which programs running in the terminal could distinguish? Arrow keys and the Delete key, for example, produce different input sequences in all these cases. This could plausibly be solved as part of #325, but doesn't strictly require customizability.
Collaborator

This is a longstanding weakness of the xterm input protocol (which most other terminals emulate) and is quite well documented here. foot already does emit some distinct escape sequences for certain extended keys (beyond the basic xterm protocol) but, as you've seen, it's still not comprehensive.

In theory it's possible for foot to start emitting distinct sequences for some of the key combos that are still missing, but it's not possible to solve all of the weaknesses of the xterm protocol in a way that doesn't cause breakage in apps that aren't prepared to deal with it. Hence why the new kitty keyboard protocol (also described in the link above) is only enabled on request and has various levels of verbosity depending on the needs of the application.

There are a few extended keyboard modes that can be enabled on request in xterm (and other terminals), but they're quite limited and (IMO) poorly designed.

I think applicatations that want to support binding any and all key combos would be best served by supporting the kitty protocol. The basic encoding scheme is already supported by some applications (and other terminals) because it's based on the existing CSI u encoding that was proposed separately a few years back.

There's already an open issue (#319) to track adding support for this new protocol to foot.

This is a longstanding weakness of the xterm input protocol (which most other terminals emulate) and is quite well documented [here](https://sw.kovidgoyal.net/kitty/keyboard-protocol/). `foot` already does emit some distinct escape sequences for certain extended keys (beyond the basic xterm protocol) but, as you've seen, it's still not comprehensive. In theory it's possible for foot to start emitting distinct sequences for *some* of the key combos that are still missing, but it's not possible to solve *all* of the weaknesses of the xterm protocol in a way that doesn't cause breakage in apps that aren't prepared to deal with it. Hence why the new kitty keyboard protocol (also described in the link above) is only enabled on request and has various levels of verbosity depending on the needs of the application. There are a few extended keyboard [modes](https://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:modifyOtherKeys) that can be enabled on request in xterm (and other terminals), but they're quite limited and (IMO) poorly designed. I think applicatations that want to support binding any and all key combos would be best served by supporting the kitty protocol. The basic encoding scheme is already supported by some applications (and other terminals) because it's based on the existing [CSI u](http://www.leonerd.org.uk/hacks/fixterms/) encoding that was proposed separately a few years back. There's already an open issue (#319) to track adding support for this new protocol to foot.
Poster

Ok, it sounds like this can be considered a dupe/subset of implementing Kitty's protocol. Thanks for the explanation.

Ok, it sounds like this can be considered a dupe/subset of implementing Kitty's protocol. Thanks for the explanation.
feeptr closed this issue 4 months ago
Owner

We could add generic styled 27...~ escapes for some of the backspace combinations. Applications with generic key decoding might recognize them.

But I think it's better to leave things the way they are, and spend our time on the kitty protocol instead.

We _could_ add generic styled `27...~` escapes for some of the backspace combinations. Applications with generic key decoding _might_ recognize them. But I think it's better to leave things the way they are, and spend our time on the kitty protocol instead.
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.