crossterm
crossterm copied to clipboard
Tracking: Missing key combinations
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) #669, #508Shift + Enter= modifiers::NONE (iTerm2, Terminal.app, gnome-terminal,VSCode Integrated Terminal) #669Alt + Enter= modifiers::ALT (iTerm2, Terminal.app, VSCode Integrated Terminal) #669Alt + Enter= modifiers::NONE (iTerm2, Terminal.app) #669Cmd + Arrow Right= Some gibberish events (IntelliJ IDEA Terminal) #597ALT + [= doesnt work.ALT + ]Doesnt work.Ctrl+Backspace= Missing modifier (iTerm2) #575, #504Alt+Backspace= Missing modifier (iTerm2) #575, #504Shift + F3Key Event not read (ubunutu) #513- [ ] Scroll up/down two finger gesture Macos (kitty) #668
- [ ] Ctrl+shift+Letters only gives the modifier ctrl (unix) #719
- [ ] Mouse up/down/move events never have KeyModifiers applied (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.
@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?
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.
@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.
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.
This issue tracks all kinds of missing key combinations so can not be closed as there are still some left
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) https://github.com/crossterm-rs/crossterm/issues/669, https://github.com/crossterm-rs/crossterm/issues/508
another question: they corresponding issues are closed in favor of this one, right?
- i guess you can unreference the issue #723 from this
tracking list - in favor of this comment https://github.com/crossterm-rs/crossterm/issues/723#issuecomment-1287767847
note: im using
- manjaro OS
- alacritty terminal (also kitty, working in both of them)
- xfce DE
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.
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.
Please join the discord for questions like this, prefer to keep this thread short
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.
Ctrl+shift+Letters only gives the modifier ctrl (unix) https://github.com/crossterm-rs/crossterm/issues/719
this works in termwiz (linux) so its probably doable
@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-readon 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
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) })
just making it clear that #669 is still unresolved – shift/ctrl + enter works on Windows but not on Linux or macOS
I am unable to get Shift + Enter to register while running cargo r --example event-read in Kitty, within Linux.
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
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"] }