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

Shift + F3 Key Event not read. #513

Closed
thinkingreed opened this issue Nov 15, 2020 · 5 comments
Closed

Shift + F3 Key Event not read. #513

thinkingreed opened this issue Nov 15, 2020 · 5 comments

Comments

@thinkingreed
Copy link

Shift + F3 Key Event not read.
Shift + F2 and Shift + F4 are read correctly.

■ Verification environment
・ Ubuntu 20.04
・ Ubuntu20.04 on WSL
・ Ubuntu 18.04

■ Program
Implemented as in the example below.
crossterm/examples/event-stream-tokio.rs

Sorry to trouble you, but please confirm.

@TimonPost
Copy link
Member

TimonPost commented Nov 15, 2020

I validated it, it seems true that SHIFT + F3 is not correctly handled. The other F keys seem to behave perfectly.

There must be something wrong at one the following places:

https://github.com/crossterm-rs/crossterm/blob/master/src/event/sys/unix/parse.rs#L223
https://github.com/crossterm-rs/crossterm/blob/master/src/event/sys/unix/parse.rs#L259
https://github.com/crossterm-rs/crossterm/blob/master/src/event/sys/unix/parse.rs#L51

I can not see directly where this problem comes from, for that we need to debug and print the ESCAPE CODE SHIFT + F3 generates.

@thinkingreed
Copy link
Author

I understand. Thank you for watching.
I will also analyze the weekend.

@MitMaro
Copy link
Contributor

MitMaro commented Jan 27, 2021

Did some digging into this tonight:

The issue seems to stem from the match here:

match buffer[buffer.len() - 1] {

On my system at least, Shift + F3 produces a buffer of [27, 91, 49, 59, 50, 82], which incorrectly matches the b'R' arm of the match.

This matches the CSI for the cursor position, I'm not sure how this can be handled.

@thinkingreed
Copy link
Author

As @MitMaro says, b'R'=> on line 162 is determined first, which seems to be a problem.
This is a rough fix, but you can avoid it by making the following fix.

        b'R'=> parse_csi_cursor_position (buffer),       
                   ↓↓↓↓↓↓↓↓↓↓↓
         b'R' => {
             let s = std::str::from_utf8(&buffer[2..buffer.len() - 1])
                 .map_err(|_| could_not_parse_event_error())?;
             let mut split = s.split(';');
             let y = next_parsed::<u16>(&mut split)?;
             let x = next_parsed::<u16>(&mut split)?;
             return if parse_modifiers(y as u8) == KeyModifiers::SHIFT && x == 2 {
                 parse_csi_modifier_key_code(buffer)
             } else {
                 parse_csi_cursor_position(buffer)
             };
         }

If you can avoid duplication of control code for cursor position acquisition,
it seems to be the best but difficult, and it seems more important to enable Shift + F3 than part of cursor position acquisition.
Please consider that.

@TimonPost
Copy link
Member

Closing in favor of #685.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants