Bug 61968

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