fix: inconsistent Shift key behavior on Unix and Windows

[ndtoan96]

Fix #166

[ndtoan96]

What is your autoformat setting, I use the default one which comes with rust-analyzer, seems like it is different from yours.

[sxyazi]

uh, I use rustfmt nightly and https://github.com/sxyazi/yazi/blob/main/rustfmt.toml as its config

[sxyazi]

I tested it and it recognized <S-a> as a:

{ on = [ "<S-a>" ], exec = "arrow 5" },

When I press a triggers arrow 5

[ndtoan96]

In my opinion, a keymap <S-a> does not make sense, we can just use A. If you want to support <S-a> style, then we will have to think about all other cases, for example <C-S-/> vs <C-?>. And if we take different keyboard layouts into the picture (French one for example), things will get quite complicated because we don't know which character is the "shifted" one.

[sxyazi]

I think not supporting <S-a> should result in nothing happening; let it fail silently, just like Yazi's current behavior, rather than recognizing it as a.

[ndtoan96]

I've flashed a mini Linux on my USB to quickly check. There is inconsistency between Linux and Windows key event:

Key	Windows	Linux
Shift + a	Char('A') + SHIFT	Char('A') + SHIFT
Shift + /	Char('?') + SHIFT	Char('?') + 0x0

Then I found this issue: crossterm-rs/crossterm#421

Looks like in the past they fix the inconsistency for alphabetic characters, but not for other shifted characters. I'll report this issue to crossterm and see if they can fix it from upstream. If they cannot, we have to adapt with the different behavior between OS.

[ndtoan96]

Can you help me check again? I decided to work around the inconsistency for now because it kinda breaks the app on Windows. I'll come back to this issue later if the crossterm team decides to address it.

[sxyazi]

It worked on my side, I'll merge it, thanks @ndtoan96