bugGNU nano - Bugs: bug #49636, Shift+Alt+[arrow] does not work...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #49636: Shift+Alt+[arrow] does not work properly in rxvt terminal

Submitter:  David Lawrence Ramsey <dolorous>
Submitted:  Thu 17 Nov 2016 09:18:09 PM UTC
   
 
Severity:  3 - Normal Status:  Fixed
Assigned to:  dolorous Open/Closed:  Closed

Jump to the original submission

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.)

Benno Schulenberg <bens>
Group administrator
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.

David Lawrence Ramsey <dolorous>
Group Member
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.

Benno Schulenberg <bens>
Group administrator
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).

David Lawrence Ramsey <dolorous>
Group Member
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.

Benno Schulenberg <bens>
Group administrator
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?

David Lawrence Ramsey <dolorous>
Group Member
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.

Benno Schulenberg <bens>
Group administrator
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.

David Lawrence Ramsey <dolorous>
Group Member
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

Benno Schulenberg <bens>
Group administrator
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?

David Lawrence Ramsey <dolorous>
Group Member
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.

Benno Schulenberg <bens>
Group administrator
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.

David Lawrence Ramsey <dolorous>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #39008:  nano-rxvtshiftalt.patch added by dolorous (2KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bens (Posted a comment)
  • -email is unavailable- added by dolorous (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-12-13 bens Open/ClosedOpen Closed
    2016-11-27 bens Assigned tobens dolorous
    2016-11-26 bens StatusIn Progress Fixed
        Summarymake Shift+Alt+[arrow] work properly in rxvt terminal Shift+Alt+[arrow] does not work properly in rxvt terminal
    2016-11-19 bens SummaryMake Shift-Alt-[arrow] work properly in rxvt terminal make Shift+Alt+[arrow] work properly in rxvt terminal
    2016-11-18 bens StatusNone In Progress
        Assigned toNone bens
    2016-11-17 dolorous Attached File- Added nano-rxvtshiftalt.patch, #39008

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code