Bug 100695 - PATCH: makes xterms modified cursorkeys match gnome-terminal
Summary: PATCH: makes xterms modified cursorkeys match gnome-terminal
Alias: None
Product: Red Hat Linux Beta
Classification: Retired
Component: xterm
Version: beta1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-07-24 13:54 UTC by Hans de Goede
Modified: 2007-04-18 16:56 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2003-08-01 08:48:11 UTC

Attachments (Terms of Use)
patch bringing xterm inline with gnome-terminal (4.33 KB, patch)
2003-07-24 13:55 UTC, Hans de Goede
no flags Details | Diff

Description Hans de Goede 2003-07-24 13:54:32 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703

Description of problem:
I'm (once again) busy trying to make all the x terminal emulators behave
identical. One of the problems is that xterm, gnome-terminal and konsole behave
different for cursor and/or function keys with modifiers (alt, ctrl, shift)

Short story:

The attached patch brings xterm fully-inline with gnome-terminal and partial
inline with konsole, the rest needs to be fixed in konsole, I know what I'm
doing so just apply it :)

Read below for the long story:

For the function keys gnome-terminal and konsole seem te agree on how the
modifer keys should be reported to the application, xterm also has identical
behaviour once you remove the shift + function key bindings override from the
XTerm app-defaults resource file. With these removed the only difference between
the 3 term. emulators is that xterm seems to ignore the alt modifier.

The attached patch for the XTerm app-defaults file removes the shift F-key
bindings and adds alt F-key bindings mimicking gnome-terminal and konsole with
this patch applied the F-key behaviour for all 3 terminals is identical.

The cursor keys are a different story, xterm and gnome-terminal both have
different ways of reporting these to the application whereas konsole just
ignores them.

The attached patch makes xterms behaviour identical to gnome-terminal,
-I think gnome-terminals way is technically better
-gnome-terminal is the default terminal in a default RH setup, so I would rather
not touch it
-some applications already expect the gnome-terminal way of reporting mod-keys.
Try this for example:
-start gnome-terminal (with just plain bash)
-type "touch aap noot mies" (and do not press enter!)
-use ctrl-left and ctrl-right to walk through the words on the cli
-now try the same in xterm.

Comment 1 Hans de Goede 2003-07-24 13:55:19 UTC
Created attachment 93107 [details]
patch bringing xterm inline with gnome-terminal

Comment 2 Mike A. Harris 2003-08-01 08:48:11 UTC
I won't make this change to Red Hat xterm, because xterm users expect xterm
to work the way it always has by default.  Changing that default on a whim only
stands to make all existing xterm users upset who are used to it working the way
it does now, and then be upset with Red Hat for changing the default behaviour.

However, if the change is made by XFree86.org themselves or the xterm
maintainer, that is a different story, as it is not then a local Red Hat

Please make xterm enhancement requests such as this directly to the upstream
xterm author Thomas Dickey.  The easiest way to do this is to file a RFE in
XFree86.org bugzilla located at http://bugs.xfree86.org

If your enhancement is accepted by XFree86.org into CVS it will appear in a
future release of Red Hat Linux when XFree86 is updated.

Comment 3 Hans de Goede 2004-06-01 08:31:04 UTC
Perhaps this bug should be reopened, it is currently being discussed
under bug 122815 (where al these bugs seem to be coming together :)

Thomas Dickey himself is suggesting in this bug that atleast the
alternate (and for the current state of affairs wrong) bindings for
shift-F1-F10 should be dropped.

Comment 4 Hans de Goede 2004-07-20 09:59:20 UTC
The choicen resolution for bug 122815, combined with the current xterm
package fixes this, so the resolution could be changed to next release.

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