Improved F1 through F4 handling #736
Conversation
|
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. |
|
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. |
| // 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())), |
There was a problem hiding this comment.
Wonder if this could cause compatibility issues with nonkitty sequences. Are we sure this pattern never occurs when kitty is not enabled?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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.