Why shift is hardcoded here ?
Closed this issue · 6 comments
tui-textarea/src/input/termion.rs
Line 51 in 39075bb
Why shift is hardcoded here as always false ? This is why I can't make combinations like Shift+Enter for example.
It's very misleading, when I write something like this for example and It always receives false.
Input {
key: Key::Enter,
ctrl: false,
shift: is_shift,
..
} => {
if is_shift {
textarea.insert_new_line();
}
} I've got the same issue! I've been agonizing over it. Any way to activate it?
I guess we can use crossterm::event::KeyCode, instead of using Input from tui-textarea, because KeyCode implements Into<Input>, but i didn't check if it works.
let timeout = Duration::from_millis(10);
if event::poll(timeout)? {
if let Event::Key(key_event) = event::read()? {
match key_event.code {
KeyCode::Enter if key_event.modifiers.contains(KeyModifiers::Shift) => {}
_ => self.textarea.input(key_event.into())
}
}
}I've checked this and with crossterm::KeyCode it also doesn't work. Idk why.
Why shift is hardcoded here ?
Because termion does not provide a way to handle shift modifier state.
termion::Event::Key provides Ctrl(char) and Alt(char) events so we can handle the state of ctrl and alt modifier keys. However, same functionality is not provided for shift key.
https://docs.rs/termion/latest/termion/event/enum.Key.html
There are some key combinatons with shift key like ShiftUp, ShiftLeft, ... but there is no Shift(char) generic event.
Instead, termion sends the input key as-is. For example, when Shift + a is pressed with US keyboard, termion sends Char('A'). We cannot know how the 'A' was sent. Generally it was sent by Shift + a, but it is completely up to user's keyboard layout.
So I thought shift field could not be set in the from function. You may somehow set the shift field properly later.
If there is a nice way to properly set the shift key in the from function without assuming user's keyboard layout, PR is welcome.