Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved F1 through F4 handling #736

Merged
merged 6 commits into from
Dec 28, 2022
Merged

Conversation

djarb
Copy link
Contributor

@djarb djarb commented Dec 21, 2022

There are some quirks to the handling of F1 through F4 in the Kitty keyboard protocol that crossterm was not handling, causing presses without modifiers of F1, F2, and F4 to be discarded without triggering an event. F3 shared in that problem, but had the additional problem that modified key presses, repeats, and releases were all discarded without triggering an event.

The problems with F1, F2, F4, and unmodified F3 were easily solved, just by making crossterm recognize the escape codes used to encode their unmodified key presses. The change is trivial and highly compatible.

The problems with F3 are more complex. For reasons unclear to me, the escape code sent for a modified F3 press or any F3 repeat or release is structurally identical to the escape code sent in response to a "Report Cursor Position" query, and must be disambiguated. The Kitty keyboard protocol documentation specifies that the key event version of the escape code will have the CSI followed by exactly "1;", so that byte sequence is used as a flag to distinguish the two cases.

@djarb
Copy link
Contributor Author

djarb commented Dec 23, 2022

I have reverted the special F3 handing, since I'm not satisfied with it. I'm looking for a way to provoke kitty into sending a non-ambiguous code instead.

@djarb djarb marked this pull request as draft December 23, 2022 10:56
@djarb
Copy link
Contributor Author

djarb commented Dec 27, 2022

The "CSI R" and "CSI 1 ; modifiers R" sequences representing F3 have now been removed from the kitty keyboard protocol due to this ambiguity. Only the "CSI 13 ; modifers ~" escape sequence for the key is now allowed, which crossterm already supports.

@djarb djarb marked this pull request as ready for review December 27, 2022 04:16
// as the 1 in 'CSI 1 P' etc. must be omitted if there are no
// modifiers pressed:
// https://sw.kovidgoyal.net/kitty/keyboard-protocol/#legacy-functional-keys
b'P' => Some(Event::Key(KeyCode::F(1).into())),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wonder if this could cause compatibility issues with nonkitty sequences. Are we sure this pattern never occurs when kitty is not enabled?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There aren't any conflicts in the xterm documentation for sequences sent from the terminal starting with CSI and immediately terminated by P, Q, or S.

The closest is CSI ps P with ps having a default value of 1 (so it can be omitted, shortening the sequence to CSI P), but that is a sequence sent to the terminal from the program, not the other way around.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, then it is fine. If in future it becomes an issue we likely can split it out and use this pr changes to check if kitty is enabled and check for those sequences.

@TimonPost TimonPost merged commit 4383f8f into crossterm-rs:master Dec 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants