What about "Shift", "Alt" and "Ctrl"

[BlockyDeer]

I can't find anything about how to get the state of "Shift", "Alt" and "Ctrl" in this crate. Are they missing?

[lemunozm]

Hi @BlockyDeer, yes they're missing.

Those keys do not generate any event in the terminal.

For some keys, you can try to infer them, i.e., you obtained 'A' instead of 'a', but that could also be due because Caps lock is enabled.

[BlockyDeer]

Can I use the event of Crossterm to get events for those keys?

[lemunozm]

I think crossterm does not generate this kind of event. At least not for "standard" terminals. The x11 lib can generate that, but it's difficult to sync with the terminal key because they are totally different processes.

I am not sure if there exists an easy solution for this...

idk about ruscii, but in my engine I use smth like this to handle Ctrl+C:

use crossterm::event::{Event, KeyCode, KeyEvent, KeyEventKind, KeyEventState, KeyModifiers};

fn events() {
    if is_event_available().unwrap() {
        Event::Key(KeyEvent {
            code: KeyCode::Char('c'),
            modifiers: KeyModifiers::CONTROL,
            state: KeyEventState::NONE,
            kind: KeyEventKind::Press,
        }) => stop_program(),
    }
}

[alefnull]

hey, just popping in from another issue in this repo also related to input handling. as i mentioned over there, i was recently using ruscii in my first released app, and was having similar issues. i've since rewritten my app to use crossterm directly instead of relying on ruscii, since my little CLI toy is pretty dead simple to begin with and didn't really need the extra ruscii bits anyway.

in any case, just wanted to double up on the suggestion from @TheYahton above, as i just implemented this in my upcoming update and it works like a charm. i'm using 'Q', and <Ctrl+C> all as possible inputs to exit the program, and they all work flawlessly.