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.

Created attachment 49156 [details] [review]
Fix for this different behaviour (from xterm)

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

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)

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

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.

Also see bug 337252

*** Bug 434921 has been marked as a duplicate of this bug. ***

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

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.

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.

Is this still relevant?  We've not had any regression reports recently, so I rather close this and similar bugs.

Shift-F4 is giving 1;2S instead of Create New File in Midnight Commander.
Is this a same bug or another one?

Ctrl-End maps to exactly the same as End - is this the same or a different bug?

(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

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

XFCE's Terminal 0.4.0 that based on vte has the same problem:
http://bugzilla.xfce.org/show_bug.cgi?id=5937

This was recently fixed.

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