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:
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".
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
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.
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 *VT100.modifyCursorKeys:0 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. Thanks guys.