Sat 26 Nov 2016 11:55:53 AM UTC, comment #11:
Fixed in git, 059c8ef. Thanks for the patch.
(The Shift+Home/End issue has been fixed in 3cc561e.)
|
Sat 26 Nov 2016 03:59:43 AM UTC, comment #10:
Good to know, and thank you.
For the record, I've done some more testing, and Shift+Alt+[arrow], Shift+Home, and Shift+End generate the same sequences under Eterm that they do under rxvt.
|
Fri 25 Nov 2016 07:03:03 PM UTC, comment #9:
(It took me a while to get a Slackware-derivative installed (Salix 14.2), and then to get a network connection in order to install rxvt. The good thing was: that I didn't need to install /anything/ extra to get nano to build from git -- very nice.)
Indeed, on Slackware no --rebindkeypad is needed to make ncurses produce full escape sequences instead of single-integer keycodes preceded by ^[. Strange... Maybe Ubuntu misconfigured their ncurses somehow? We would have to compare how Debian and Slackware compile their ncurses.
But how silly that on rxvt Shift+Arrow and Shift+Ctrl+Arrow produce the exact same code. Oh, the weird choices people make. It seems we will just have to poll the modifier state ourselves also when running under X, not just on a linux console.
Anyway, your patch makes it possible to have Shift+Alt+Arrow work on an rxvt, so I will a apply that (tomorrow). Another patch will be needed to distinguish Home/End from Shift+Home/End.
|
Tue 22 Nov 2016 04:20:52 PM UTC, comment #8:
My rxvt is from Slackware 14.2, no changes from its default build. The build script uses:
./configure --prefix=/usr --enable-languages --enable-utmp --enable-wtmp --enable-xpm-background --enable-transparency --enable-menubar --enable-graphics --enable-rxvt-scroll --enable-next-scroll --enable-xterm-scroll --enable-xim --enable-frills --enable-linespace --enable-24bit --enable-keepscrolling --enable-mousewheel --enable-slipwheeling --enable-xgetdefault --enable-old-selection
and there's one patch to build with libutempter. Short of building rxvt a few times with different options, I'm not sure what is affecting the keypad.
Understood with regard to Alt-[arrow]. And you're right on key_defined() (unless you want to fall back on tigetstr() or something, but that seems to be curses-specific in a different way).
|
Tue 22 Nov 2016 09:48:35 AM UTC, comment #7:
Weird that your rxvt does not need --rebindkeypad to produce full key sequences. Are you on a Debian(-derived) system? Or did you compile rxvt yourself? Or...?
I did not intend for <Alt+Arrow> to always behave als <Arrow> -- if they are distinguishable, they should stay distinct. I just meant that if they cannot be distinguished, it is okay for <Alt+Arrow> to behave as if <Alt> was not pressed.
The code for interpreting escape sequences cannot be simplified, because we cannot rely on key_defined() being available -- which it won't if someone has compiled ncurses in its default form.
But... now I see why Shift+Home/End are not working on rxvt. <Home> produces "^[[7~", and <Shift+Home> "^[[7$" -- but the interpretation code only looks as far as the "7" and never checks what the character coming after it is. Even if there were zero other sequences that started with "^[[7", it is wrong not to check for the /full/ sequence. Some of these full checks were added earlier this year (commit e3dbffc for example), but apparently not for all cases yet.
|
Mon 21 Nov 2016 07:05:21 PM UTC, comment #6:
Actually, I don't have rebindkeypad set at all, and specifying it doesn't seem to change anything on my end. Thanks for the info on your end.
And consistently supporting Alt-[arrow key] as [arrow key] will require adding support for a few more escape sequences. xterm generates Esc [ 1 ; 3 A for Alt-Up (in the usual A B C D sequence for all four arrow keys). Not to mention, the current version of Terminal I'm using now generates the same codes as xterm for Shift-[arrow key] instead of what nano's code handles. Maybe the escape sequence reading code can be simplified somewhat by using get_keycode() to get the codes for Shift-[arrow key] and Alt-[arrow key] instead?
|
Sat 19 Nov 2016 10:37:42 AM UTC, comment #5:
When using --rebindkeypad, your patch makes Shift+Alt+Arrow work in an rxvt terminal here (instead of producing the "Unbound key" error). So, presumably, you have 'set rebindkeypad' in your .nanorc?
When pressing Alt plus a printable character, rxvt correctly produces ^[ followed by the exact printable character -- no messing with high bits occurs. The strange thing is (when not using --rebindkeypad) that when pressing Alt with one of the movement keys, rxvt will produce ^[ followed by the ncurses code for that movement key (KEY_LEFT, KEY_HOME, etcetra). This is weird, and I have no idea how rxvt achieves that.
Another strange thing: when using --rebindkeypad on rxvt (both with and without your patch), Alt+Left /and/ Alt+Right /both/ jump a word left, while Alt+Up does <Home> and Alt+Down does <End>. I think none of this should happen: Alt+Arrow should do either the same as Arrow, or produce "Unbound key", like on a Gnome Terminal.
|
Fri 18 Nov 2016 07:01:08 PM UTC, comment #4:
Okay, this is bizarre, as I'm getting the same escape sequences on this end.
Maybe the difference is in X11 terminal settings somewhere? I notice the Shift-Alt codes you're getting are out of ASCII range due to having the high bit set. Does Alt-[some printable character] act like Escape-[some printable character] on your rxvt, or does it produce a printable character with the high bit set (in ISO-8859-1 or the like)? Mine does the former.
|
Fri 18 Nov 2016 05:03:14 PM UTC, comment #3:
I've tested with the same version as you: "Rxvt v2.7.10 - released: 26 MARCH 2003".
The relevant escape codes when using M-V before the keystrokes:
^[Od Ctrl+Left
^[Oc Ctrl+Right
^[[d Shift+Left
^[[c Shift+Right
^[[d Shift+Ctrl+Left
^[[c Shift+Ctrl+Right
^[^[[d Shift+Alt+Left
^[^[[c Shift+Alt+Right
^[^[[a Shift+Alt+Up
^[^[[b Shift+Alt+Down
The Shift+Alt combinations appear to produce the correct codes, the ones that your patch is testing for, but still... it don't work, not here. :|
When using --enable-debug, and grepping the resulting debug output for "hex codes", after typing Alt+Left, Alt+Right, Alt+Up, Alt+Down, shows this:
get_key_buffer(): the sequence of hex codes: 1b 104
get_key_buffer(): the sequence of hex codes: 1b 105
get_key_buffer(): the sequence of hex codes: 1b 103
get_key_buffer(): the sequence of hex codes: 1b 102
The same series with also Shift held:
get_key_buffer(): the sequence of hex codes: 1b 189
get_key_buffer(): the sequence of hex codes: 1b 192
get_key_buffer(): the sequence of hex codes: 1b 208
get_key_buffer(): the sequence of hex codes: 1b 201
|
Fri 18 Nov 2016 03:29:58 PM UTC, comment #2:
Version 2.7.10 (which is old, but the same version I tested rxvt support with when adding nano's support for all those escape sequences in the first place).
Ctrl-Shift sequences don't work as expected in rxvt, but that's because Ctrl-Shift-[arrow] generate the same escape sequences as Shift-[arrow], so they act like Shift-[arrow], and I don't think there's an easy way to work around that.
Good to know why things are done that way. What version of rxvt are you using? And what escape sequences do those key combos spit out when in verbatim input mode?
|
Fri 18 Nov 2016 12:43:45 PM UTC, comment #1:
Hi David,
Which version of rxvt are you using? Because here Shift+Alt+Up/Down just says "Unbound key", also after your patch. And Shift+Alt+Left/Right do the same as without holding Alt, also after your patch.
The same goes for the combinations with Ctrl instead of Alt. Do the combinations with Ctrl work correctly for you on an rxvt? That is: does Shift+Ctrl+Right select a word, and Shift+Ctrl+Down select a block? If not, can they be made to work?
The combinations with Shift+Alt are really just workarounds for when Shift+Home/End and Shift+PgUp/PgDn don't work in some terminal emulator. The first pair appears to work on rxvt, but the latter does nothing.
|
Thu 17 Nov 2016 09:18:09 PM UTC, original submission:
In current nano 2.7.1-git, Shift-Alt-[arrow] in rxvt erroneously acts just like [arrow]. After some testing, it seems that rxvt generates Esc Esc [ a through d for those keys, and nano only handles Esc Esc [ A through D for iterm2 Option sequences. The attached patch fixes this, and updates related comments.
I'm not certain whether nano should be mapping those rxvt sequences to shiftaltup, etc. to be translated later, or mapping them directly to their translated values (as the iTerm2 code turns Esc Esc A and B into KEY_HOME and KEY_END directly); the patch takes the former approach.
|