Bug 127773 - Ctrl-Arrow keys do not work in xterm
Ctrl-Arrow keys do not work in xterm
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: xterm (Show other bugs)
1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-13 13:02 EDT by Eli
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-07-16 21:49:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Eli 2004-07-13 13:02:48 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Gecko/20031114

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
xterm.
In xterm, ^V^Left displays ^[[1;5D
In Konsole, ^V^Left displays ^[[5D


Version-Release number of selected component (if applicable):
xterm-179-5

How reproducible:
Always

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.

Additional info:
Comment 1 Thomas E. Dickey 2004-07-13 20:24:36 EDT
man xterm (modifyCursorKeys).  The report is referring to obsolete
behavior (see xterm patch #167 2002/8/27).
Comment 2 Mike A. Harris 2004-07-13 21:04:55 EDT
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".
Comment 3 Eli 2004-07-13 21:34:05 EDT
Eh, what?

I run xterm, the Ctrl-Arrow keys don't work like they do in the other
applications.  What about this is NOTABUG?

Eli
Comment 4 Mike A. Harris 2004-07-13 23:05:57 EDT
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
clarify.

Thanks in advance.
Comment 5 Thomas E. Dickey 2004-07-14 05:29:52 EDT
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.
Comment 6 Eli 2004-07-14 08:33:57 EDT
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.
Comment 7 Thomas E. Dickey 2004-07-14 15:26:34 EDT
gnome-terminal and konsole don't pay any attention to xterm's
resource settings.  Adding something like
    *VT100.modifyCursorKeys:0
to your .Xdefaults shouldn't have any other effect.
Comment 8 Eli 2004-07-14 21:21:16 EDT
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.
Comment 9 Thomas E. Dickey 2004-07-16 16:14:23 EDT
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).
Comment 10 Mike A. Harris 2004-07-16 18:29:57 EDT
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.
Comment 11 Thomas E. Dickey 2004-07-16 18:36:26 EDT
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).
Comment 12 Eli 2004-07-16 19:43:05 EDT
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.
Comment 13 Thomas E. Dickey 2004-07-16 19:48:47 EDT
In principle yes.  (I don't know where Redhat has it configured,
but it's just a different character string).
Comment 14 Mike A. Harris 2004-07-16 21:49:49 EDT
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.

Thanks guys.

Note You need to log in before you can comment on or make changes to this bug.