Red Hat Bugzilla – Bug 127773
Ctrl-Arrow keys do not work in xterm
Last modified: 2007-11-30 17:10:46 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Description of problem:
Ctrl-Left and Ctrl-Right should move the cursor by a word. However,
in an xterm I get "5D" or "5C" respectively, inserted into the
commandline instaed. The Ctrl-arrow keys work in Konsole, but not in
In xterm, ^V^Left displays ^[[1;5D
In Konsole, ^V^Left displays ^[[5D
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. start an xterm
2. type some words
3. press Ctrl-Left
Actual Results: "5D" is inserted into the commandline.
Expected Results: It should have moved the cursor left by a word.
man xterm (modifyCursorKeys). The report is referring to obsolete
behavior (see xterm patch #167 2002/8/27).
Thanks for the info Thomas. Pasting the manpage info for this option
here for others who might stumble across the problem who haven't
read the manpage:
modifyCursorKeys (class ModifyCursorKeys)
Tells how to handle the special case where control-, shift-,
alt- or meta-modifiers are used to add a parameter to the
escape sequence returned by a cursor-key. Set it to 0 to use
the old/obsolete behavior. Set it to 1 to prefix modified
sequences with CSI. Set it to 2 to force the modifier to be
the second parameter. Set it to 3 to mark the sequence with a
'>' to hint that it is private. The default is ``2''.
Closing bug as "NOTABUG".
I run xterm, the Ctrl-Arrow keys don't work like they do in the other
applications. What about this is NOTABUG?
From my interpretation of the upstream xterm maintainer's (Thomas)
comments in comment #1, and my reading of the xterm manpage which
I pasted above in comment #2, this is a configuration issue and
not an xterm bug. The default xterm behaviuor is what you have
right now, however if you prefer the older "obsolete" behaviour
that is documented in the xterm manpage, you can reconfigure
xterm's X resources manually to provide you the obsolete behaviour
if you wish.
If my interpretation of Thomas' comment is correct, then this is
not a bug. I'll leave it open for now for Thomas to confirm or
Thanks in advance.
It's not a bug (in xterm). gnome-terminal and konsole copied
the keyboard layout that I made for xterm in
patch #94 1999/3/27, but did not track the improvement made in
patch #167 2002/8/27. Essentially the problem was that Emacs
users pointed out that putting the modifier code in the first
parameter gave unexpected behavior from applications which
interpreted the parameters. (Bash users tend to just use hardcoded
strings, while zsh has had a tput-based solution for a few years).
If it's a bug, then add it to gnome-terminal's heap.
See http://invisible-island.net/xterm/xterm.log.html for history.
Ok, I think we're talking past each other. When I press Ctrl-Arrow, I
expect the cursor to move by a word. If it fails to do that, it is a
bug (in something). Therefore, this is a bug.
Now, I think what you are telling me is that the sequence of
characters generated by Ctrl-Arrow within xterm is an improved
sequence from what gnome-terminal and konsole use (due to technical
issues of how that sequence is interpreted by some applications).
That's fine, but somewhere the other half of the configuration got
lost -- the part that translates the improved character sequence into
word-based cursor motion.
Now, would changing that configuration to make xterm work break
gnome-terminal and konsole? If so, then the configuration needs to
change, and a bug needs to be filed against both of them.
gnome-terminal and konsole don't pay any attention to xterm's
resource settings. Adding something like
to your .Xdefaults shouldn't have any other effect.
As a temporary workaround,
echo "*VT100.modifyCursorKeys:0" > ~/.Xdefaults
<restart X or logout and back in>
fixes the behavior for this user on this system.
After a bit of Googling I found that this works system wide:
echo "*VT100.modifyCursorKeys:0" >> /usr/lib/X11/app-defaults/XTerm
That file is part of the xterm package. I'd make a patch, but I'm
having trouble getting the source rpm for it at the moment. :/
Is that the solution you want merged into Fedora?
Thanks for your help.
It's a solution for some people. (I have no idea whether it is
desirable for Fedora, since it preserves obsolete behavior -
and at some point that would lead as in a couple of other bug
reports, finding that gnome-terminal copies the newer behavior
and the Redhat packager is reluctant to modify the xterm package).
It's not that I'm reluctant to modify xterm, but rather that I prefer
to keep our xterm as close to upstream xterm as possible. When we
modify any package, and it inconveniences some user, it sometimes
upsets user(s), and also sometimes upsets the upstream maintainer(s)
of the given package. Our xterm modifications have done both in the
past, and so I believe the closer I can keep our xterm to upstream,
the happier the upstream maintainer will be, and the less problems
users will report to us.
The only exception I'd like to keep is for when a particular upstream
default is unsuitable for what our own userbase expects. Fortunately,
such differences are kept to a minimum, and I prefer to minimize them
further if possible, either by removing our customizations, or by
upstream integration of the change or a similar change (such as
the default scrollback buffer change recently).
In other words, I want to stick with your defaults wherever possible,
and only make changes if there is a strong enough demand from our
users for a change from the default, but the change isn't considered
ok to you for upstream inclusion by default.
In the world of managing packages, it is often difficult and
sometimes impossible to make decisions that please everyone out
there. ;o) So, I try to do the second best, and please as many
people as possible, including the upstream maintainer if possible. ;o)
I think we should preserve the upstream xterm behaviour in this case,
and that people who prefer the obsolete behaviour can easily change
the default behaviour at their own option by modifying their own
local xterm configuration. The "default" IMHO should be what the
current software version considers default by default. ;o)
So, for this issue, I'm going to stick with the stock xterm default,
as I believe that is the most sensible, and I assume you do too, as
you've made it the default. ;o) If you (Thomas) think I should
change it in our packages anyway, despite the current upstream
default, I will consider the change however.
Let me know what you prefer Thomas, and I'll handle it once I've
returned from my vacation (Aug 1).
Thanks for all of your feedback.
no problem (I made it the default because it involves fewer
complaints overall - if I see that it becomes a more frequent
issue, I'll summarize it on my FAQ).
Can we get Ctrl-Arrow to work using a different change? In other
words, can we keep the "new improved" xterm and modify bash (or
whatever is interpreting the sequence from xterm) to recognize the
"new improved" key code? (I tried to use bind to change the
association of backward-word, etc. but I couldn't get it to work.)
Would that be an acceptible change instead?
Fundamentally, Ctrl-Arrow moves the cursor by a word in every other
application, including earlier xterms, and the fact that it does not
do that in the current xterm is a BUG and needs to be changed in
Fedora, by default.
In principle yes. (I don't know where Redhat has it configured,
but it's just a different character string).
Thomas: Ok, sounds reasonable to me. This is the only report I've
had so far about this, so I don't consider it a major issue per se.
Now that we've discussed this and have concensus, I'm setting this
back to NOTABUG.
Eli: If you prefer, please feel free to file a bug report against
the bash component to have it recognize xterm's modern behaviour.
Our bash package maintainer can then review the request for
consideration. You may wish to prefix your bug summary with "RFE"
to indicate request for enhancement also.