Characters from keys with modifiers are ignored in input fields

[SchuhBaum]

What system are you running Yazi on?

Windows

What terminal are you running Yazi in?

Powershell

yazi --debug output

Yazi
    Version: 0.3.1 (VERGEN_IDEMPOTENT_OUTPUT 2024-08-22)
    Debug  : true
    OS     : windows-x86_64 (windows)

Ya
    Version: 0.3.1 (VERGEN_IDEMPOTENT_OUTPUT 2024-08-22)

Emulator
    Emulator.via_env: ("", "")
    Emulator.via_csi: Ok(Unknown([]))
    Emulator.detect : Unknown([])

Adapter
    Adapter.matches: Chafa

Desktop
    XDG_SESSION_TYPE: None
    WAYLAND_DISPLAY : None
    DISPLAY         : None

SSH
    shared.in_ssh_connection: false

WSL
    /proc/sys/fs/binfmt_misc/WSLInterop: false

Variables
    SHELL              : None
    EDITOR             : None
    VISUAL             : None
    YAZI_FILE_ONE      : None
    YAZI_CONFIG_HOME   : None

Text Opener
    default: Some(Opener { run: "nvim \"%*\"", block: true, orphan: false, desc: "nvim", for_: None, spread: true })
    block  : Some(Opener { run: "nvim \"%*\"", block: true, orphan: false, desc: "nvim", for_: None, spread: true })

Multiplexers
    TMUX               : false
    tmux version       : program not found
    ZELLIJ_SESSION_NAME: None
    Zellij version     : program not found

Dependencies
    file             : 5.45
    ueberzugpp       : program not found
    ffmpegthumbnailer: program not found
    magick           : program not found
    fzf              : 0.51.0
    fd               : 10.1.0
    rg               : 14.1.0
    chafa            : program not found
    zoxide           : 0.9.2
    7z               : 24.05
    7zz              : program not found
    jq               : program not found


--------------------------------------------------
When reporting a bug, please also upload the `yazi.log` log file - only upload the most recent content by time.
You can find it in the "C:\\Users\\andre\\AppData\\Roaming\\yazi\\state" directory.

Did you try the latest nightly build to see if the problem got fixed?

No, and I'll explain why below

Describe the bug

Characters that require modifiers (like ctrl, alt) are ignored in input fields like "cd --interactive". The german keyboard layout requires modifiers for some characters. Examples are @ (ctrl+alt+q), \ (ctrl+alt+ß) and ~ (ctrl+alt++). These characters are filtered out when pasting text as well ("C:\hello" becomes "C:hello").

Minimal reproducer

1. Use a keyboard with german layout. (Or maybe just change the keyboard layout in Windows. The key ß is located in the number row between 0 and ´.)
2. Open cd --interactive by pressing g<space>.
3. Press ctrl+alt+ß for the character \.
4. Notice that no character is inserted and the input field stays empty.

Anything else?

No response

[sxyazi]

Please apply this patch and build Yazi in debug mode, then check the log file to see what key was reported

--- yazi/yazi-fm/src/app/app.rs
+++ yazi/yazi-fm/src/app/app_new.rs
@@ -81,7 +81,10 @@
 	fn dispatch_render(&mut self) { NEED_RENDER.store(true, Ordering::Relaxed); }
 
 	#[inline]
-	fn dispatch_key(&mut self, key: KeyEvent) { Router::new(self).route(Key::from(key)); }
+	fn dispatch_key(&mut self, key: KeyEvent) {
+		tracing::error!(?key);
+		Router::new(self).route(Key::from(key));
+	}
 
 	#[inline]
 	fn dispatch_paste(&mut self, str: String) {

[SchuhBaum]

From the logs:

  �[2m2024-08-22T15:45:58.492737Z�[0m �[31mERROR�[0m �[1;31myazi::app::app�[0m�[31m: �[1;31mkey�[0m�[31m: KeyEvent { code: Char('\\'), modifiers: KeyModifiers(CONTROL | ALT), kind: Press, state: KeyEventState(0x0) }�[0m
    �[2;3mat�[0m yazi-fm\src\app\app.rs:86

From the source code:
The function plain() is used to filter out characters when modifiers are pressed as well.

impl Key {
	#[inline]
	pub fn plain(&self) -> Option<char> {
		match self.code {
			KeyCode::Char(c) if !self.ctrl && !self.alt && !self.super_ => Some(c),
			_ => None,
		}
	}
}

[sxyazi]

Based on the logs, it seems that crossterm reported an incorrect key event. The ctrl+alt+ß combination should be reported as \ instead of ctrl+alt+\. We can't remove the checks for ctrl and alt in the plain() function because that would affect the normal behavior of ctrl+alt+\.

I don't think there's anything Yazi can do about this, as Yazi simply receives the events from crossterm as they are without any additional processing, I suggest reporting this issue to crossterm so their devs can investigate it further.

[joshka]

Hey there - @sxyazi. To help avoid users adding more issues on the crossterm repo about keyboard bindings, there's a central issue for these at crossterm-rs/crossterm#685. That issue contains debugging and more information about what terminals support what.

[sxyazi]

Hey @joshka, thanks for linking to the issue!

It seems that the problem described there is a bit different - it's not about missing key combinations; instead, it's reporting incorrect key combinations, specifically wrong modifiers. Does this still apply to that issue?

[joshka]

I think so, but I could be wrong.
The best bet though is to ensure that key has some meaningful value in the user's terminal outside of crossterm, and then spend some time on the debugging steps mentioned in the linked issue. Wrong modifiers is just a specialization of the problem that terminal input codes are non-standardized and many places where they will differ. Adding non PC-101 layouts in the mix makes this even more difficult.

[SchuhBaum]

The ctrl+alt+ß combination should be reported as \ instead of ctrl+alt+\.

This might be wrong. Other combinations like shift+a are reported as shift+A and not just A. Therefore, the function plain(..) needs to account for that. It does that by ignoring the shift modifier.

Crossterm could handle these cases because it has a function that can return the character based on the keyboard layout. So it can determine that ß is the base character when ctrl+alt+\ is reported. But it is likely intended that modifiers are not consumed when the character changes.
Yazi already handles cases where Windows reports a shift modifier but Unix does not. It seems that it is not crossterm's responsibility to change the way that Windows reports modifiers.

[sxyazi]

If I understand correctly, the functions of Shift and Ctrl / Alt are different. Shift is used to produce the uppercase form of printable characters.

For example, pressing Shift + a gives you A. I don't quite get why crossterm would report it as Shift + A, I haven't read through crossterm's code, but I guess it's easier to implement this way. In practice, though, this isn't really a problem.

Note the term I mentioned, "printable characters". This means A will show up in the input, which is fine.

However, Ctrl and Alt have a different purpose. They're used to generate control characters. For instance, Ctrl + a produces a character with an ASCII code of 1 (SOH), which is not printable, so it won't show up in the input, and that's correct behavior.

❯ showkey
Type any key to see the sequence it sends.
Terminate with your shell interrupt <CTL-C=ETX> or quit <FS> character.
<CTL-A=SOH>

The issue here is that I'm still unsure how to handle real ctrl+alt+\ if we ignore ctrl/alt in the plain() method. It's important to note that this method is a general-purpose one. In your case, it's ctrl+alt+\, but it affects all ctrl/alt combinations, like ctrl+a, alt+a, ctrl+alt+a, and so on.

[SchuhBaum]

Wouldn't the real ctrl+alt+\ produce a control character instead of a printable character? The problem is that printable characters are being ignored.

Crossterm is consistent with what plain Powershell reports. It looks more like a Windows / Powershell behavior.