-
Notifications
You must be signed in to change notification settings - Fork 83
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
Fix Home and End keys on macOS #521
Conversation
at the beginning and end of readline (and readmultiline). This fixes Home and End keys not working on macOS: ruby/irb#330 We need to go into keyboard_transmit mode because only then do some terminals (including xterm) actually send the sequences they specify in terminfo.
We already have key bindings for the arrow keys 'kcuu1', 'kcud1', 'kcuf1', and 'kcub1'. This hack only existed because the arrow keys key bindings weren't working (for some terminals) because reline wasn't putting the terminal into keypad transmit mode. The escape sequences for 'cuu', 'cud', 'cuf', and 'cub' are not what the terminal sends when arrow keys are pressed. They are what you send to the terminal to tell it to move the cursor. It just so happens that in some terminals (well xterm at least), the escape sequences for 'cuu', 'cud', 'cuf', and 'cub' with the "%p1%d" part ommitted from the middle happen to result in the escape sequences for the arrow keys in normal mode, but we don't need to rely on this anymore.
Note many Linux users are unaffected by this problem only because an unrelated bug is causing That bug was fixed in fiddle and incorporated into ruby here in Oct 2022, but it's still broken in reline because reline needs to call I can fix that line, but I'll save it for a separate PR after this one goes in; and to be extra safe, I'll try to help get #433 in as well beforehand to reduce the chance of regression. |
@ima1zumi @st0012 @tompng can you please take a look at this PR? It fixes ruby/irb#330 once and for all, a bug that was reported 1.5 years ago; a variety of workarounds have been found since then, but we should fix it so people don't have to rely on workarounds. It also removes an ugly hack that is no longer necessary thanks to this fix. Also, keep in mind that the only reason more Linux users are not also seeing and reporting problems with Home and End is likely because (due to another bug) libncurses is failing to load, and then reline doesn't use terminfo at all but instead uses the comprehensive key binding list. If you'd like to reproduce Home and End keys not working on Linux, 1. make sure you are using an xterm-based terminal, and 2. change |
I confirmed that this pull request fixes the problem but I have some concerns. Is application mode necessary? Does application mode always make escape sequence line up with terminfo? The main problem is that Reline does not accept some escape sequence and such escape sequence exists more in normal mode, less in application mode. Using the less-problematic mode is a workaround. Not a fundamental fix. |
I understand the hesitation, but a quick search shows that other apps do it, and even some shells like zsh: I think readline works because it relies on hard-coded mappings in the code rather than relying on terminfo.
I do agree that given the down_arrow sends But the argument is kinda moot because there is no terminfo entry for that. There is a terminfo capability named "kcud1" which means "down-arrow key", but there is no capname for "down-arrow key while holding down option". So we never would or even could add that to
I see it more this way: "The main problem is escape sequences exist in normal mode when an application runs in normal mode". Terminfo can't provide two escape sequences for the same capname, so it just provides the application mode escape sequence. Therefore, applications that want to use terminfo should enter application mode.
I see it as a fundamental fix because everything I've read suggests that applications that want to use terminfo should be in application mode, for example:
If there are any serious concerns with entering application mode, then I agree with ditching this PR and going with #433 or #567 instead. So far the only problem I can think of with enter application mode is just that it seems wrong to do that for something that is not actually a full-screen application (although with multi-line support it kinda gets closer). Practically, the only downside I can think of is that if a process is terminated abruptly, we might leave the terminal in application mode. I suppose that could be a valid concern. Update: I did think of another downside to entering application mode. The time it takes to send the escape sequence for smkx (which in xterm is like 7 bytes) and rmkx (also 7 bytes) I think could cause a noticeable delay between prompts when running over a very slow connection. If we are concerned about this, then I think it is a good argument for choosing a different solution. |
There are two application mode settings. DECKPAM(Application Keypad) and DECCKM(Application Cursor Keys). Emacs and Vim enables both. Enabling both will make the input sequence line up more with terminfo.
I confirmed macOS Terminal.app sends Currently, I don't feel we should use application mode, especially enabling only half of the settings. I think we should do a fix or workaround first without application mode. If there is more reason we should use application mode, we can reconsider it but in a separate issue from HOME and END keys. AppendixIn https://vt100.net/docs/vt510-rm/DECCKM.html, it says
And in https://vt100.net/docs/vt100-ug/chapter3.html DECCKM section, it says
"application sequences" or "application functions" might be different and we should use terminfo. In "Minimum requirements for VT100 emulation" section of https://www.real-world-systems.com/docs/ANSIcode.html, keyboards will send these sequences.
Since most terminal emulators are vt100 compatible, there is no ambiguity for these escape sequences. I think there are no need for terminfo-like thing for normal mode, but that does not mean we should always use application mode. My plan is to add these keys and |
And
Dang, I didn't notice that. And I confirmed as well with iTerm that hitting enter on my keypad sends "\EOM" in application mode. So going into application mode will have a lot more side effects than I realized 😢 .
Yeah, at this point I have to agree that we should not use application mode. Thanks for helping me see the other side effects it has.
Yeah, based on my research as well, the sequences for arrow keys in normal mode appears to be pretty much standard across pretty much all terminals.
Agreed. I think we can feel good about hard-coding the escape sequences "\e[A", "\e[B", "\e[C", "\e[D" for the arrow keys as you have done in #567.
Agreed. The cursor key escape sequences appear to be pretty standard. I have verified this as well with my research and some testing.
Sounds like a good plan. Although "\e[F" and "\e[H" for Home and End are not as standard as the cursor keys sequences, I think we should go ahead and push forward with #567. |
Closing in favor of #567 |
Re-opening until after #567 is merged. |
This is fixed by #569 |
Fix ruby/irb#330 by entering keyboard transmit mode (aka application mode) to ensure the escape sequences line up with terminfo.
Also, remove a hack that is no longer needed (see commit comment for explanation).
This replaces #462, which had some issues and was never finished up.