Do not include consumed modifiers in key escape sequences sent to the client application #378

Manually merged
dnkl merged 2 commits from consume-modifiers-for-client-application into master 9 months ago
dnkl commented 9 months ago
Owner

When sending a key escape sequence to the client application, do not include consumed modifiers.

As dicussed in #376, foot currently ignores consumed modifiers completely. This PR does not adress all issues related to this, but fixes only the modifiers sent to the client application.

On a swedish keyboard, pressing ctrl+shift+0 produces \E[27;6;61~ (61 is the = character) before this, PR, and with this PR \E[27;5;61~.

Fixes part of #376

When sending a key escape sequence to the client application, do not include consumed modifiers. As dicussed in #376, foot currently ignores consumed modifiers completely. This PR does not adress all issues related to this, but fixes only the modifiers sent to the client application. On a [swedish keyboard](https://en.wikipedia.org/wiki/File:KB_Sweden.svg), pressing <kbd>ctrl</kbd>+<kbd>shift</kbd>+<kbd>0</kbd> produces `\E[27;6;61~` (61 is the `=` character) **before** this, PR, and **with** this PR `\E[27;5;61~`. Fixes part of #376
dnkl added the
bug
label 9 months ago
Poster
Owner

FWIW, XTerm implements foot's current behavior. I.e. if we merge this, we will no longer match XTerm's emitted sequences.

Not sure if we should just blindly do what XTerm does, but it does mean we should think twice before merging this.

FWIW, XTerm implements foot's **current** behavior. I.e. if we merge this, we will no longer match XTerm's emitted sequences. Not sure if we should just blindly do what XTerm does, but it does mean we should think twice before merging this.
Poster
Owner

@craigbarnes I've been thinking this one over, and I don't see any reasons not to merge this. Any objections?

@craigbarnes I've been thinking this one over, and I don't see any reasons not to merge this. Any objections?
Collaborator

I can't think of any specific objections at the moment, but I do have some reservations about diverging from the xterm behavior. Since the CSI 27 ~ encoding scheme originates from xterm, it seems like subtly changing it could cause problems with existing clients, since they almost certainly implemented their support for it while testing against xterm.

Since all the various issues around shifted keys can be so confusing (and sometimes conflicting), I think we need to come up with a list of all the problems that should to be taken into account and be explicit about how changes like this would improve (or worsen) each of them.

I can't think of any specific objections at the moment, but I do have some reservations about diverging from the xterm behavior. Since the `CSI 27 ~` encoding scheme originates from xterm, it seems like subtly changing it could cause problems with existing clients, since they almost certainly implemented their support for it while testing against xterm. Since all the various issues around shifted keys can be so confusing (and sometimes conflicting), I think we need to come up with a list of all the problems that should to be taken into account and be explicit about how changes like this would improve (or worsen) each of them.
dnkl force-pushed consume-modifiers-for-client-application from d5479a9973 to 9ef8ae3e79 9 months ago
dnkl force-pushed consume-modifiers-for-client-application from 9ef8ae3e79 to e4f164d958 9 months ago
dnkl merged commit 098bc2771b into master manually 9 months ago
The pull request has been manually merged as 098bc2771b.
Sign in to join this conversation.
Loading…
There is no content yet.