From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020312 Description of problem: When i try to use ctrl-left (arrow) or ctrl-right arrow in mc or mcedit, in an xterm, it just shows the keycodes it's recieving (5C and 5D), and not doing next-word / prev-word. (It is working in bash, emacs, etc also it does work in text mode, its only in X that it messes up) When i rpm -e `rpm -qa | grep XFree86` and install the XFree86 rpm's from redhat 7.2 (the XFree 4.0.1 rpms), everything works again in mc / mcedit. So it would seem the keybindings or keycodes changed between the X versions? What can i / need to, change (in Xresources?) to make this work in XFree 4.0.2 & mc / mcedit ? Any help and / or sugestions are grealy apreciated (ps, to reproduce, goto X, start an xterm, type 'mcedit', type in some words in the editor, and try to do ctrl+left_arrow. This should make your cursor jump to the previous word. Instead it is now showing '5D') How reproducible: Always Steps to Reproduce: 1. start mcedit 2. press ctrl-leftarrow Actual Results: '5D' appears instead of going prev-word Expected Results: prev-word Additional info: When i downgrade skipjacks XFree86 to Enigma's XFree (4.1.0), the prev-word / next-word do work.
Does it work in gnome-terminal/konsole? (i.e. is this xterm-specific?)
(fraid i dont have kde installed, so can not comment on konsole) xterm: doesnt work uxterm: as xterm xterm3d: as xterm rxvt: shows 'ddd' and 'ccc' instead of 5D and 5C, but no work gnome-terminal: does nothing (no output,but also no next/prev word) (ps, forinstance with 'vi', next/prev-word _does_ work in xterm, but not in rxvt, and also does nothing in gnome-terminal)
Who knows which behavior is right - we need to figure out which sequence should be sent for this, and make all the terminals do it.
Well it is hard to call any behaviour correct. Every terminal on every different unix platform has different keys for stuff like this. (Which is why termcap / xresources/etc is such a messy situation) All i know is it used to work, and does not anymore ;-) (and would cause me from having to downgrade the xfree instalation 200+ workstations i admin to get rh 7.3 to work properly on them since mc / mcedit is very populair ;-/)
Mike did you patch xterm or did it just change upstream?
Hi, I'm a friend of the reporter, and the guy who suggested that RH uses the debian keyboard guidelines. I also did most of the ncurses, and xterm & friends patches in the 6.x days to get this done. Since I know a lott about keyboardbindings Chris asked me to check this out. At first I couldn't get the "correct" behaviour even in 7.2. It turns out that Chris has his mcedit in Emacs mode. Making alt-b and alt-f. The "enhancement" in 7.2 requested in bug 48783. Made ctrl-arrows emit these esc-sequences. But as discussed in bug 48783 this caused problems. Although I do not agree with the reasons given in bug 48783 to undo the enhancement, I do agree with the fact that it shouldn't be in the default distro. There is no wel defined behaviour for ctrl+arrows in a terminal claiming to be xterm. But alt-b / alt-f although convienient most certainly isn't correct behaviour. What does this al mean for this bug? a) It can be closed, since this only worked in 7.2 because of pure luck, it is not a well defined behaviour b) It can also be made a RFE since mcedit could be made aware of the ESC [5C sequence for ctrl-right and ESC [5D for ctrl-left which is used by al newer versions of xterm. So if anything comes close to a well defined behaviour, these ESC sequences do. This has to be hardcoded in mc and mcedit, since there is no way to get this from terminfo. And it should be noted that untill today (AFAIK) only the real xterm does that, other terminal emulators claiming to be xterm don't c) Chris meanwhile should add the following lines to the keybindings already in /usr/X11R6/lib/X11/app-defaults/XTerm: Ctrl <Key>Left string(0x1b) string("b") \n\ Ctrl <Key>Right string(0x1b) string("f") \n\ Or if you don't want to edit this each upgrade, add the entire keybindings part in this file + these 2 lines to /etc/X11/Xresources, and don't forget to put XTerm* in front of it. Thats all, now letts close this bug and get on :)
The Xterm resources patch (Patch7 in the specfile), is attached below for perusal of what it is adding to the one supplied by XFree86.org Just for the record, my official stance on xterm related bugs in XFree86 mirrors what Preston has said before to me many times now. xterm is not officially supported in Red Hat Linux. It is provided for usage, since many people are accustomized to using it, and want to remain so for their own reasons. The supported terminals are gnome-terminal and konsole. Being unsupported to me means that I will not add _any_ "enhancements" to xterm *EVER* for any reason. All ehancements requests will generally be closed WONTFIX depending on the specific request. Requests to modify the resources file will definitely be declined. Actual bugs in xterm will be briefly examined in order to determine if there is a simple obvious fix that is considered extremely safe and sensible without much effort. Any deep bug or bug requiring extensive knowledge of xterm internals, or lengthy debugging will be deferred to upstream xterm maintainers, hopefully to be fixed in future releases of XFree86. Bugs reported against xterm that involve the existing changes to the resources file for xterm, will result in whatever the enhancement was that put it there being removed. Since we do not support xterm, we should be shipping xterm in as close a state to XFree86.org as possible, since XFree86.org is NOT going to want to support our own modified version, or modified X resources file. I've been explicitly told this by the upstream xterm maintainer, and I can't disagree with his reasons either. So in summary, if we have made a change to xterm or its resources file, which causes it to work incorrectly, then that change will be gracefully removed no problem. Any general xterm bugs will be given a priority 3 lookover for obvious fixes. Security related bugs are in a special category of their own of course. All other xterm bugs are considered unsupported, please report upstream. I just thought I would document this in bugzilla, so I have something to cut and paste into future bug reports against xterm if need be. Now to attach that file..
Created attachment 53444 [details] XFree86 4.2.0 xtermresources patch currently being applied
Again, just for the record.. if someone knows of a bug which is specifically caused by our modifications to xterm resources, by all means, let me know via bugzilla and I will remove the offending change. If xterm requires changes to operate correctly beyond what is shipped by XFree86.org, then there is no reason those changes should not be made by XFree86.org and picked up by us as well. Hope this helps clarify xterm related issues. Please catch me in IRC or email to discuss in realtime if anyone would like to. #xfree86 on OPN (or internal IRC for hatters). Thanks guys.
Ps, hans that should be with a colon between the <key>....: string so the lines should be: Ctrl <Key>Left: string(0x1b) string("b") \n\ Ctrl <Key>Right: string(0x1b) string("f") \n\ (just for the records incase anyone uses this bug as resource in the future)
About the semicolon, your right. About the official stance, I agree. What I meant when I said that I disagreed with the reason given in bug 48783 is that not only should the ctrl-arrow bindings to alt b/f not be included because of the official stance, but also because those bindings are dead wrong :) p.s. Shouldn't you close this bug now?
I'm not sure this should be closed, but I guess I'm not sure what else I'd do with it either. ;-)