Tracking: Missing key combinations

[TimonPost]

Parsing ANSI codes to input events is a pain. There is no good way to tell which terminals implement which key combinations. Therefore it might occur that some terminals do support certain key presses while others dont. This issue serves as a tracking issue and lists various keys that are reported missing. Either it might be that crossterm has not yet implemented it or that the terminal doesn't support the key combination. Please post your missing keys in this issue.

The supported events are often even different in each terminal emulator. For background on the extended ways that terminals can report keys see see https://sw.kovidgoyal.net/kitty/keyboard-protocol/ and http://www.leonerd.org.uk/hacks/fixterms/. Crossterm supports the kitty protocol using the PushKeyboardEnhancementFlags command.

How to debug

This code is responsible for parsing a bytes buffer to an event. If you miss a key, it is useful if you can print the buffer with println!("Buffer: {:?}, buffer) in this function. Then report that value with the missing keys in this issue. That way we can trace back and see if crossterm should add parsing logic for that buffer.

Reported Missing

• Ctrl + Enter = modifiers::NONE (iTerm2, Terminal.app, gnome-terminal,VSCode Integrated Terminal) Shift/Ctrl + Enter returns modifiers::NONE #669, inconsistent reporting of ^Enter #508
• Shift + Enter = modifiers::NONE (iTerm2, Terminal.app, gnome-terminal,VSCode Integrated Terminal) Shift/Ctrl + Enter returns modifiers::NONE #669
• Alt + Enter = modifiers::ALT (iTerm2, Terminal.app, VSCode Integrated Terminal) Shift/Ctrl + Enter returns modifiers::NONE #669
• Alt + Enter = modifiers::NONE (iTerm2, Terminal.app) Shift/Ctrl + Enter returns modifiers::NONE #669
• Cmd + Arrow Right = Some gibberish events (IntelliJ IDEA Terminal) Badly handles Cmd + Arrow in IntelliJ Terminal #597
• ALT + [ = doesnt work.
• ALT + ] Doesnt work.
• Ctrl+Backspace = Missing modifier (iTerm2) macOS, backspace, and modifiers #575, Backspace with modifiers not recognised as backspace #504
• Alt+Backspace = Missing modifier (iTerm2) macOS, backspace, and modifiers #575, Backspace with modifiers not recognised as backspace #504
• Shift + F3 Key Event not read (ubunutu) Shift + F3 Key Event not read. #513
• Scroll up/down two finger gesture Macos (kitty) EventStream produces sequence of KeyEvents instead of mouse ScrollUp/ScrollDown #668
• Ctrl+shift+Letters only gives the modifier ctrl (unix) Ctrl+shift+Letters only gives the modifier ctrl #719
• Mouse up/down/move events never have KeyModifiers applied (konsole) no mouse modifiers using konsole #708

note: not all are solved

Note

Please do not create a separate issue for missing combinations, instead comment in this issue such that I can update the above list. The above list contains combinations that might have been fixed or missing combinations that are still to be fixed.

[cloudultima3164]

@TimonPost
Sorry for the sudden comment. I was just writing up a simple tui using crossterm as a backend, and I ran into this issue. I'm not very experienced with coding, so I could be overlooking something, but it looks like the function for parsing events that you linked above never tries to match Enter with some key modifiers based on input. Again, I'm not really familiar, but could adding a few more match cases could take care of most enter-related issues?

[TimonPost]

It depends if the terminal supports escape codes for certain special key combinations. It indeed might be the case that it can be mapped but isn't implemented yet, in that case, it's a simple addition to the existing parsing code. If you have any in mind feel free to add them.

[cloudultima3164]

@TimonPost
Thanks for the quick response! I checked this out in my local environment (I'm using fish on Pop!_OS). It looks like it's not as simple as I was hoping, and I kind of understand your concern better.
As you mentioned, I printed out the buffer, the event, and labeled what was actually pressed on the keyboard. I can now see that there probably is no way to tell that Ctrl or Shift were even pressed in these cases.

Edit: Same result using bash as well.

event_log.txt

[pianohacker]

Can this be closed with the addition of the keyboard enhancement feature to 0.25?

That support is limited to certain terminals, but most of these are unsupportable without it.

[TimonPost]

This issue tracks all kinds of missing key combinations so can not be closed as there are still some left

[alexzanderr]

i want to ask a question about Reported Missing list.

the items that dont have a todo box are considered solved (i.e. the keys are now supported and detectable), are considered not yet implemented or they cant be implemented so they are left alone in darkness?

for example

• Ctrl + Enter = modifiers::NONE (iTerm2, Terminal.app, gnome-terminal,VSCode Integrated Terminal) Shift/Ctrl + Enter returns modifiers::NONE #669, inconsistent reporting of ^Enter #508

another question: they corresponding issues are closed in favor of this one, right?

• i guess you can unreference the issue ctrl + backspace doesnt work? or its not supported, cuz linux terminal stuff? #723 from this tracking list
• in favor of this comment ctrl + backspace doesnt work? or its not supported, cuz linux terminal stuff? #723 (comment)

note: im using

• manjaro OS
• alacritty terminal (also kitty, working in both of them)
• xfce DE

[TimonPost]

Yes, I need to go through them again and add boxes for combinations that have no solution yet. Will add a note that not all are solved.

[alexzanderr]

another technical question, please, is there a way to get a Vec<u8> from the unsupported keys, something like RawKey, so that maybe i can solve the problem temporarily for my code?

to at least to see what ctrl + enter does look like as bytes, for example.

cant see anything like that in the docs.

[TimonPost]

Please join the discord for questions like this, prefer to keep this thread short

[coastalwhite]

As mentioned in #771. Shift+Tab in the TTY is also broken. It produces Alt+Tab, it should probably produce BackShift or Shift+Tab. I am uncertain whether this is a limitation of the TTY.

[sigmaSd]

Ctrl+shift+Letters only gives the modifier ctrl (unix) #719

this works in termwiz (linux) so its probably doable

[sigmaSd]

@coastalwhite which terminal/os shift+tab work for me (linux/wezterm)

For anyone trying to report a bug in key combo please do:

• test with the event-read example so cargo r --exampe event-read on this repo
• test a terminal that supports kitty protocol on unix so wezterm/kitty (if wezterm make sure to have enable_kitty_keyboard = true)
• mention os/terminal

[coastalwhite]

Sorry for not being entirely clear. This is purely a Linux TTY issue, it works fine in any non-TTY terminal I have tried (Alacritty, Kitty, etc.). So if you run cargo r --example event-read and press Shift+Tab it will give back:

Event: Key(KeyEvent { code: Tab, modifiers: KeyModifiers(ALT), kind: Press, state: KeyEventState(0x0) })

[Araxeus]

just making it clear that #669 is still unresolved – shift/ctrl + enter works on Windows but not on Linux or macOS

[Xithrius]

I am unable to get Shift + Enter to register while running cargo r --example event-read in Kitty, within Linux.

[sigmaSd]

Ctrl+shift+Letters only gives the modifier ctrl (unix) #719

this works in termwiz (linux) so its probably doable

turns out thiis works with the kitty protocol, in linux wezterm (with enable_kitty_keyboard=true) I have this working now ctrl+shift+letter ctrl+shift+enter

[ryan-rushton]

Just reporting in with any modifier + backspace is not working as I only see the backspace key come through. Debugging I see the following

System is a Macbook M1 Pro with OSX Version 14.2.1 (23C71). Using crossterm through the ratatui component template with crossterm = { version = "0.27.0", features = ["serde", "event-stream"] }

[SchuhBaum]

The debug steps are for Unix. I have added a log_to_file(..) function to the function parse_key_event_record(key_event: &KeyEventRecord) -> Option<WindowsKeyEvent> in the file parse.rs of the Windows branch.

I only used one example for this. There are other cases. If there is no general solution then I can post logs for these too. The output is (with added comments):

// pressed ctrl+alt+ß; this should give \ and not ctrl+alt+\;
TEMP: KeyEventRecord { key_down: true, repeat_count: 1, virtual_key_code: 17, virtual_scan_code: 29, u_char: 0, control_key_state: ControlKeyState(40) }
TEMP: KeyEventRecord { key_down: true, repeat_count: 1, virtual_key_code: 219, virtual_scan_code: 12, u_char: 0, control_key_state: ControlKeyState(40) }
TEMP: KeyEventRecord { key_down: true, repeat_count: 1, virtual_key_code: 18, virtual_scan_code: 56, u_char: 0, control_key_state: ControlKeyState(42) }
TEMP: KeyEventRecord { key_down: false, repeat_count: 1, virtual_key_code: 219, virtual_scan_code: 12, u_char: 92, control_key_state: ControlKeyState(42) }
TEMP: KeyEventRecord { key_down: false, repeat_count: 1, virtual_key_code: 18, virtual_scan_code: 56, u_char: 0, control_key_state: ControlKeyState(40) }
TEMP: KeyEventRecord { key_down: false, repeat_count: 1, virtual_key_code: 17, virtual_scan_code: 29, u_char: 0, control_key_state: ControlKeyState(32) }

// pressed ß; this works as expected;
TEMP: KeyEventRecord { key_down: true, repeat_count: 1, virtual_key_code: 219, virtual_scan_code: 12, u_char: 223, control_key_state: ControlKeyState(32) }
TEMP: KeyEventRecord { key_down: false, repeat_count: 1, virtual_key_code: 219, virtual_scan_code: 12, u_char: 223, control_key_state: ControlKeyState(32) }

// pressed q to quit yazi;
TEMP: KeyEventRecord { key_down: true, repeat_count: 1, virtual_key_code: 81, virtual_scan_code: 16, u_char: 113, control_key_state: ControlKeyState(32) }

[joshka]

It might make sense to actually add logging to this (I'm partial to the tracing crate rather than the log crate as the structured logging is often more useful than unstructured approach in logs).
Log this at a trace level in the two methods and enable tracing_subscriber in the key-display / other examples to help make it easy to debug.

[SchuhBaum]

I can try that.

I have a general question. Modifiers are intended to be consumed when they change the character, correct?
For example, shift+a is A and not shift+A, shift+ß is ? and not shift+?, ctrl+alt+ß is \ and not ctrl+alt+\, ctrl+alt+q is @ and not ctrl+alt+@.
(There are some examples that I don't really get. In text editors and the Windows search bar shift+ctrl+alt+q gives no output and shift+ctrl+alt+ß gives ß. In Powershell shift+ctrl+alt+q gives ^Q (that should mean ctrl+Q) and shift+ctrl+alt+ß gives plain ß again.)

[joshka]

I have a general question. Modifiers are intended to be consumed when they change the character, correct?
For example, shift+a is A and not shift+A

No, shift+a is shift+A

Event: Key(KeyEvent { code: Char('a'), modifiers: KeyModifiers(0x0), kind: Press, state: KeyEventState(0x0) })
Event: Key(KeyEvent { code: Char('A'), modifiers: KeyModifiers(SHIFT), kind: Press, state: KeyEventState(0x0) })

My guess is that this was implemented this way to make it easy to treat KeyCode::Char(c) as something which can just be copied into whatever string is being created to represent the user's input, and so it needs no translation.

(There are some examples that I don't really get. In text editors and the Windows search bar shift+ctrl+alt+q gives no output and shift+ctrl+alt+ß gives ß. In Powershell shift+ctrl+alt+q gives ^Q (that should mean ctrl+Q) and shift+ctrl+alt+ß gives plain ß again.)

I don't really have too many answers on this. Those questions really come down to reading the various terminal emulators documentation and digging into their quirks to understand what is happening. Non-english key handling is something I don't know a lot about, and I'd guess it's probably got some differences on each operating system.

BTW, to set expectations, I'm by no means an expert on crossterm. Just helping out where I can because we use it in Ratatui a lot.

[SchuhBaum]

Oh wow, thanks for pointing that out!
In that case it looks like everything is working as intended. I get back to the yazi devs and ask them if they can handle these cases. (According to the source code, they already throw away the shift in shift+? because Unix does not report shift for special characters like ß or ?.)