After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 310305 - The strings emitted by Control- and Shift- ARROW_KEYS are not the same as xterm in normal mode
The strings emitted by Control- and Shift- ARROW_KEYS are not the same as xte...
Status: RESOLVED DUPLICATE of bug 600659
Product: vte
Classification: Core
Component: general
0.11.x
Other All
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-07-14 01:20 UTC by dann
Modified: 2014-01-08 21:16 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
Fix for this different behaviour (from xterm) (1.41 KB, patch)
2005-07-14 11:05 UTC, Michele Baldessari
rejected Details | Review

Description dann 2005-07-14 01:20:36 UTC
Please describe the problem:
Example:
The string emitted by  Control-Up (press C-v C-up at the bash prompt in a
gnome-terminal) is ^[[5D, xterm emits ^[[1;5D 
In application mode the strings emitted are the same. 

The same is true for all all the arrow keys and all modifier combinations.

It would be better if vte would implement the xterm behavior.

Steps to reproduce:
1. In a gnome-terminal at the bash prompt type C-v C-up


Actual results:
The string ^[[5D is displayed

Expected results:
I would expect the string ^[[1;5D to be displayed, as it happens when doing the
same thing in bash running in an xterm (or konsole too).

Does this happen every time?
Yes

Other information:
Comment 1 Michele Baldessari 2005-07-14 11:03:59 UTC
Hi Dann,

does this difference break anything? I ask because I think there'd be loads of 
people screaming if it did.

Anyhow, I'll attach the four liner fix.
Comment 2 Michele Baldessari 2005-07-14 11:05:23 UTC
Created attachment 49156 [details] [review]
Fix for this different behaviour (from xterm)
Comment 3 dann 2005-07-14 12:17:45 UTC
Thanks for the quick fix!

> does this difference break anything? I ask because I think there'd be loads of 
> people screaming if it did.


I am not aware of anything that uses these.
Your fix does not deal with "left" and "right" which suffer from the
same issue.

C-left and C-right are potentially useful, they could be bound to
forward-word and backward-word in bash/tcsh.

Oh, and I found another problem too: "Home" and "End" do not emit the
correct string in either app or default mode. Try pressing "Home" and
"End" at the bash prompt in both an xterm and gnome-terminal. In
gnome-terminal a "~" will be inserted, in an xterm the cursor will
move to the beginning and end of the line. Try the same inside an
"emacs -nw" window, it does not work for gnome-terminal... The
terminfo entry specifies some of these strings, try infocmp | grep -i home


Here's the strings that should be emitted:
Key            App mode          Default mode
home            ^[OH             ^[[H
S-home          ^[[1;2H          ^[[1;2H
C-home          ^[[1;5H          ^[[1;5H
A-home          ^[[1;3H          ^[[1;3H
C-S-home        ^[[1;6H          ^[[1;6H
C-A-home        ^[[1;7H          ^[[1;7H
S-A-home        ^[[1;4H          ^[[1;4H
C-S-A-home      ^[[1;8H          ^[[1;8H

Similar for end, just replace "H" with "F".

Comment 4 Michele Baldessari 2005-07-14 13:04:03 UTC
Hi Dann,

yes it was just a quick fix/test nothing complete by any means. 
Just wondering though, Home and End work fine here, both in bash and in emacs.
Also Ctrl-Left and Ctrl-Right do already work for forward-word and backward-word
in bash.

What system/termcap etc. are you using?

(If you want to check exactly what vte is doing termcap-wise, just recompile vte
using --enable-debugging and then export VTE_DEBUG_FLAGS=all and use the "vte" 
app inside the vte/src directory. You'll see something like:
Setting emulation to `xterm'...Loading termcap
`/home/devel/gnome/INSTALL//share/vte/termcap/xterm'..._vte_termcap_create()
at the begginning)
Comment 5 dann 2005-07-14 17:45:44 UTC
> Just wondering though, Home and End work fine here, both in bash and in emacs.

Yeah, sorry about that, it seems that the test account I was using had a stale
~/.terminfo entry that I didn't remember about... Ignore everything I said about
the Home and End keys.

> Also Ctrl-Left and Ctrl-Right do already work for forward-word and > 
> backward-word in bash.

Well in FC4 they are bound in /etc/inputrc (you might have something similar):
# for linux console and RH/Debian xterm
[snip]
"\e[5C": forward-word
"\e[5D": backward-word
"\e[1;5C": forward-word
"\e[1;5D": backward-word

I think it's still a good idea to add your patch, it does not seem wise to have 
just a few keys that are different from xterm... 
Comment 6 Leonardo Boshell 2005-08-05 15:40:37 UTC
As long as there's some interest in trying to emulate xterm's behaviour more
closely, I'd add that two particular keyboard sequences I particularly miss on
gnome-terminal are Ctrl+Home and Ctrl+End. The strings listed on comment #3 seem
to be accurate, which, along with the patch from comment #2, helped me craft a
small patch to make Ctrl+Home and Ctrl+End work.

The patch just adds the following element to the _vte_keymap_GDK_Home array:

{cursor_all, keypad_all, fkey_all, GDK_CONTROL_MASK, _VTE_CAP_ESC "[1;5H", -1, NULL}

and something similar is done for _vte_keymap_GDK_End.

I wish I could come up with a more general solution that actually covered other
keys/modifiers, but most of those _vte_keymap_entry structs look like magic to
me, so I'll keep studying the code for now.
Comment 7 Chris Wilson 2007-04-26 19:37:53 UTC
Also see bug 337252
Comment 8 Chris Wilson 2007-05-01 15:45:11 UTC
*** Bug 434921 has been marked as a duplicate of this bug. ***
Comment 9 Mart Raudsepp 2007-06-19 02:05:20 UTC
I wouldn't be so sure about bug 434921 being a duplicate - ctrl+left/right arrow (and shift+left/right arrow probably) used to move backwards-word and forwards-word just fine in GNOME-2.16, but stopped working in GNOME-2.18 (at least on gentoo - http://bugs.gentoo.org/show_bug.cgi?id=178793), so that seems a new regression than this older feature request/bug here
Comment 10 Mart Raudsepp 2007-06-19 02:10:11 UTC
Sorry for the spam. Missed the note to Bug 337252 before. My previous comment here can be ignored, as bug 337252 covers the regression that happened from making alt+arrow to work.
Comment 11 Loïc Minier 2007-07-25 09:31:01 UTC
I'm rejecting this patch as it breaks <up> / <down> in the shell history and I received a bunch of bug reports when I tried uploading it to Debian; the patch in bug #337252 seems on a better track.
Comment 12 Behdad Esfahbod 2007-11-28 13:24:53 UTC
Is this still relevant?  We've not had any regression reports recently, so I rather close this and similar bugs.
Comment 13 vvb.backup 2008-07-03 19:07:32 UTC
Shift-F4 is giving 1;2S instead of Create New File in Midnight Commander.
Is this a same bug or another one?
Comment 14 David Fraser 2009-03-18 07:04:26 UTC
Ctrl-End maps to exactly the same as End - is this the same or a different bug?
Comment 15 David Fraser 2009-03-18 07:07:50 UTC
(In reply to comment #14)
> Ctrl-End maps to exactly the same as End - is this the same or a different bug?
> 

Apparently not - found bug 375652 for Ctrl-End and Ctrl-Home
Comment 16 sergey_feo 2009-11-28 21:44:59 UTC
Roxterm 1.13.0 that based on vte has problems with shift + up/down arrows with Midnight Commander 4.7.0-pre4 application. Shift + up/down arrows is classic hotkeys for text selection at least in DOS environment traditions. Midnight Commander can do text selection with shift + up/down arrows in xterm (v. X.Org
6.8.99.903(243)) but can't in Roxterm.

Please see Roxterm's original bugreport at

http://sourceforge.net/tracker/?func=detail&atid=698428&aid=2890032&group_id=124080
Comment 17 sergey_feo 2009-12-10 08:22:14 UTC
XFCE's Terminal 0.4.0 that based on vte has the same problem:
http://bugzilla.xfce.org/show_bug.cgi?id=5937
Comment 18 Egmont Koblinger 2014-01-08 21:16:30 UTC
This was recently fixed.

*** This bug has been marked as a duplicate of bug 600659 ***