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

Recognize Escape key when not used in escape sequence #193

Closed
Jojo4GH opened this issue Jul 28, 2024 · 6 comments · Fixed by #224
Closed

Recognize Escape key when not used in escape sequence #193

Jojo4GH opened this issue Jul 28, 2024 · 6 comments · Fixed by #224

Comments

@Jojo4GH
Copy link

Jojo4GH commented Jul 28, 2024

Moved from comment on pull request: #192 (comment)

ESC can both mean the escape key was pressed as well as be the start of an escape sequence.
It might be possible to also use a short timeout on the second read here.
Since every ESC in escape sequences is quickly followed by other characters this would allow to distinguishing from single Escape key presses and users would not need to press escape twice.

@ajalt
Copy link
Owner

ajalt commented Jul 28, 2024

That's a good idea, and I did look into that, but I wasn't able to find a timeout value that was reliable without being ususably long.

The main issue is that there's not actually an upper bound on timeouts for ANSI sequences: you can manually type ESC [ d and the program is supposed to interpret that as a left arrow key event.

@Jojo4GH
Copy link
Author

Jojo4GH commented Jul 28, 2024

The main issue is that there's not actually an upper bound on timeouts for ANSI sequences: you can manually type ESC [ d and the program is supposed to interpret that as a left arrow key event.

That's an unfortunate compatibility requirement but understandable. Maybe this timeout could be configured/enabled manually by the programmer? Some application don't want to have use cases for manually typing those sequences and they could instead configure Mordant to have the "single escape after xxx ms" behaviour.

@ajalt
Copy link
Owner

ajalt commented Jul 29, 2024

You already can! Pass a timeout to readEvent and it will report a single ESC as Escape if it doesn't receive anything else.

Feel free to try that, but I found that even with high timeout values I was still seeing escape sequences get split up.

@Jojo4GH
Copy link
Author

Jojo4GH commented Jul 29, 2024

Thanks! That seems to work even over network with just a 4 ms timeout set.

However, if I read the source correctly the same small timeout will apply to all read calls inside the readInputEvent function.
For some escape sequence read is used three or four times and setting a small timeout may lead to some unnecessary instability on top of the unavoidable one for the escape key case.
So if we read for instance ESC [, we know that the ESC was not the escape key but the beginning of a sequence and we could relax a bit with the following timeouts.
Maybe this could fix the splitting of escape sequences you have experienced?

@hubvd
Copy link
Contributor

hubvd commented Aug 17, 2024

This could be solved using the Kitty keyboard protocol for terminals that supports it.

@ajalt
Copy link
Owner

ajalt commented Sep 2, 2024

I decided to go with the short timeout approach. It means you can't type in escape sequences any more, but that seems like a much less common use case than using the escape key normally.

The Kitty protocol is interesting, but most terminals don't support it yet. So it's not a high priority, but we could open a separate issue if we still think it's worth it.

@ajalt ajalt closed this as completed in #224 Sep 2, 2024
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

Successfully merging a pull request may close this issue.

3 participants