search

crossterm-rs / crossterm

Cross platform terminal library rust
MIT License
3.26k stars 279 forks source link

Tracking: Missing key combinations #685

Open TimonPost opened 2 years ago

TimonPost commented 2 years ago

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

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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

alexzanderr commented 2 years ago

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

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

note: im using

TimonPost commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

coastalwhite commented 1 year ago

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 commented 1 year ago

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

sigmaSd commented 1 year ago

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

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

coastalwhite commented 1 year ago

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 commented 1 year ago

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

Xithrius commented 1 year ago

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

sigmaSd commented 1 year ago

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 commented 8 months ago

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

Screenshot 2024-02-25 at 9 45 14 am

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 ?.)