Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why shift is hardcoded here ? #68

Closed
0b-s3rv3r opened this issue Jun 3, 2024 · 6 comments
Closed

Why shift is hardcoded here ? #68

0b-s3rv3r opened this issue Jun 3, 2024 · 6 comments
Labels
question Further information is requested

Comments

@0b-s3rv3r
Copy link

shift: false,

Why shift is hardcoded here as always false ? This is why I can't make combinations like Shift+Enter for example.

@0b-s3rv3r
Copy link
Author

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();
   }
}          

@ProHaller
Copy link

I've got the same issue! I've been agonizing over it. Any way to activate it?

@0b-s3rv3r
Copy link
Author

0b-s3rv3r commented Jun 30, 2024

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())
                }
            }
         }

@0b-s3rv3r
Copy link
Author

I've checked this and with crossterm::KeyCode it also doesn't work. Idk why.

@rhysd rhysd added the question Further information is requested label Aug 2, 2024
@rhysd
Copy link
Owner

rhysd commented Aug 2, 2024

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.

@rhysd rhysd closed this as completed in c4f1b22 Aug 2, 2024
@rhysd
Copy link
Owner

rhysd commented Aug 2, 2024

I added some more combinations with arrow keys at 0e32eed.

termion added support for those combinations at v4. As long as shift + arrow keys combinations, shift field is set properly.

redox-os/termion@3b52dc9

rhysd added a commit that referenced this issue Aug 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants