bugGNU nano - Bugs: bug #64642, xfce4-terminal 1.1.0 regression of...


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

bug #64642: xfce4-terminal 1.1.0 regression of shift+arrow[up|down] text selection

Submitter:  Lawrence R. Steeger <lsteeger>
Submitted:  Sat 09 Sep 2023 10:11:07 PM UTC
Severity:  3 - Normal Status:  None
Assigned to:  None Open/Closed:  Closed

Sat 23 Dec 2023 12:27:15 PM UTC, comment #5: 

As this is not a bug in nano, closing.

Benno Schulenberg <bens>
Group administrator
Thu 14 Sep 2023 02:23:11 PM UTC, comment #4: 

Ow...  Most of the remarks in comment #2 were actually meant for bug #64632 -- I got confused by both issues being related to the Xfce terminal.  But anyhow: thanks for relaying.

Benno Schulenberg <bens>
Group administrator
Tue 12 Sep 2023 08:09:41 PM UTC, comment #3: 

I've relayed your comments to xfce4-terminal 1.1.0.

Lawrence R. Steeger <lsteeger>
Tue 12 Sep 2023 03:07:16 PM UTC, comment #2: 

The "^[[25~" comes from libvte.  I've edited /usr/lib/x86_64-linux-gnu/libvte-2.91.so.0.6800.0 (with nano --ignore --noconvert --nonewlines --nohelp) and replaced the occurrence of "25~" with "44~" and rebooted.  When I then run `setxkbmap nl` (where the nl map contains `replace key <CAPS> {[ F13 ]};`, then typing ^V followed by CapsLock produces a "^[[44~" sequence instead of "^[[25".

Well... I think the sequences for F13 and higher in src/keymap.cc in vte-0.72.2 are not a good choice. VTE-based terminals are not trying to imitate a Linux console, but an xterm.  So the sequences produced for function keys had better mimic the ones produced by xterm, right?

[Could you maybe relay these remarks upstream?  I refuse to solve Captchas.  Also, even though the shortcuts have now become configurable, there still is a regression: Xfce Terminal no longer falls back to passing on a shortcut when this shortcut is not applicable in the current state of the terminal (that is: when ncurses has switched to a second screen).]

Benno Schulenberg <bens>
Group administrator
Sun 10 Sep 2023 06:15:32 AM UTC, comment #1: 

Ouch.  Confirmed on a Manjaro install on my second laptop.

But the Preferences now has an extra tab: Shortcuts.  When one clears the shortcuts for scrolling the terminal up and down, text selection with Shift works again in nano.

When, however, one sets those shortcuts to Shift+Ctrl+Up/Down (what they used to be on older Xfce Terminals), then selecting blocks of text with those keystrokes in nano does not work.  In the past, one could use those keystrokes for both purposes: scrolling in the terminal and selecting blocks of texts in nano.  It would be nice if that smart behavior could return.  Preferrably also for the new default bindings Shift+Up/Down.

Benno Schulenberg <bens>
Group administrator
Sat 09 Sep 2023 10:11:07 PM UTC, original submission:  

I've submitted a bug at xfce4-terminal 1.1.0.

The use of holding shift+arrow[up|down] keys to select text in nano has been disabled by this xfce4-terminal change.

Not a nano bug, per se, but a nasty regression in xfce4-terminal.

Submitted here for informational purposes only.

Lawrence R. Steeger <lsteeger>


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

No files currently attached


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 lsteeger (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.


    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-12-23 bens Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.12.
    Corresponding source code