failing a bunch of tests 😅 not sure why

edit: Guessing this is because the simulated inputs in tests are just uppercase and not shift prefixed. So, in other words, everything works in reality, tests are just failing because of mismatching inputs.

Another approach to fix this issue could be to change keybind parsing to handle uppercase binds 🤔

Yea @mWalrus I think upper-case should work, perhaps <shift+k> and K should be equivalent.

Showing refs (Y) seems to be working just fine for me on master or v0.33.0.
On Linux (Fedora).

That's weird @altsem 🤔 I even checked back in the commit history just to make sure I wasn't going crazy, and it works for me on 0.33 release commit but not after you switched backends for Termwiz. Not sure what is going then...

I've tried these keybind definitions:

• root.show_refs = ["Y"]
• root.show_refs = ["<shift+y>"]
• root.show_refs = ["<shift+Y>"]

And only the last one works for me (on Arch Linux (btw)).

Ah, I discovered something @altsem! It works for me in the alacritty terminal, but not in the foot terminal. I wonder why that is...

That's interesting. I installed Foot, but I can't reproduce it.
Hmmmm.

I think I must've broken it with this change:

3cb28c6

That's interesting. I installed Foot, but I can't reproduce it. Hmmmm.

Oh, uhm... that's weird indeed 😅

I figured out what's happening (on my machine at least).
Termwiz running in foot reports shift-modified key presses as:

• KeyEvent { key: Char('Y'), modifiers: SHIFT }

While termwiz running in alacritty reports them as:

• KeyEvent { key: Char('Y'), modifiers: NONE }

I can "fix" the issue by modifying the key press in-flight:

match event {
    InputEvent::Key(ref mut key_event) if key_event.modifiers == Modifiers::SHIFT => {
        if let KeyCode::Char(c) = key_event.key {
            key_event.key = KeyCode::Char(c.to_ascii_uppercase());
            key_event.modifiers = Modifiers::NONE;
        }
    }
    _ => {}
}

But maybe I should do more testing to see if I can figure out why it behaves differently in the first place. Maybe it's because of differences in input handling between Wayland compositors or something funky like that.

I think I must've broken it with this change: 3cb28c6

Oh yeah, looks interesting!

this works for me: e27ac98

@altsem, can you test this commit locally and see if it works for you?

Edit: the linked commit works in foot but not in alacritty... makes sense I guess, but annoying nonetheless!

Maybe the mutate-key-event-in-transit-approach is the way to go?

That fix does work in Foot for me, but breaks it in alacritty.

Foot:

[00:00:01.631] (7ff766dd1940) INFO   KeyEvent { key: Char('y'), modifiers: NONE }
[00:00:02.149] (7ff766dd1940) INFO   KeyEvent { key: Char('Y'), modifiers: SHIFT }
[00:00:04.429] (7ff766dd1940) INFO   KeyEvent { key: Char('2'), modifiers: NONE }
[00:00:04.774] (7ff766dd1940) INFO   KeyEvent { key: Char('@'), modifiers: NONE }

Alacritty:

[00:00:00.766] (7f6f3c033940) INFO   KeyEvent { key: Char('y'), modifiers: NONE }
[00:00:01.073] (7f6f3c033940) INFO   KeyEvent { key: Char('Y'), modifiers: NONE }
[00:00:01.546] (7f6f3c033940) INFO   KeyEvent { key: Char('2'), modifiers: NONE }
[00:00:01.793] (7f6f3c033940) INFO   KeyEvent { key: Char('@'), modifiers: NONE }

Perhaps

• <shift+A> and <shift+a> should both be normalized to A.
• And likewise for any incoming event.

@altsem,

Managed to implement a working fix.
You can view the changes here: master...mWalrus:gitu:fix/restore-shift-keybinds-v3.

Should I close this PR and open a new one from that branch?

@mWalrus I went ahead and did it, will take it for some testing and merge if all is fine.
Closing this one.