Red Hat Bugzilla – Bug 78654
Meta key does not work properly in Xterm
Last modified: 2007-04-18 12:48:43 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Description of problem:
I use macros extensively in vi, many of which are bound to Meta-letter key
combinations. Upon upgrading (clean install, mkfs'd the disks) to RHL8.0 I
became unable to access these macros. Investigation revealed that instead of
sending the proper sequence, xterm was actually sending '^[letter', which was
not recognized. Further investigation reveals a setting in
/usr/X11R6/lib/app-defaults/XTerm is disabling eight bit input in xterms,
preventing the meta key from working properly. This setting is:
! Bug fix for bugzilla bug #49315
bugzilla will not allow me to view bug #49315, so I have no idea *why* this
setting was made, but it is the cause of my problem. Adding:
to ~/.Xdefaults and running 'xrdb -merge ~/.Xdefaults' makes the meta key work
properly in new xterms.
Version-Release number of selected component (if applicable):
mwl@voyager:~>rpm -qf `which xterm`
Steps to Reproduce:
1. open an xterm, start vim
2. create a simple macro: ':map <M-t> !!date<CR>'
3. Hit Meta-t (Alt-t) to execute the macro. Observe nothing happen.
Actual Results: The macro fails to execute.
Expected Results: The current line in the file should be replaced with the
output of the date command.
or b) remove/comment out '*VT100*eightBitInput: false' from
This is a minor bug with a simple workaround, but very annoying until one
discovers the workaround. It would be nice if this bit of cruft was removed
from the app-defaults file, so this common program will behave as expected.
Created attachment 86645 [details]
Patch to fix the XTerm app-defaults file
The officially supported terminal emulation software in Red Hat Linux
includes "gnome-terminal" and "konsole". xterm is provided for legacy
reasons as a convenience to users who like to have it available for
whatever their personal reasoning/needs.
It is impossible for any software in it's default configuration to
work exactly to every single user's own personal preference, however
-some- default must be made. Since xterm is no longer supported by
Red Hat, and has not been for quite some time now, we do not change
the default configuration.
I have discovered through trial and error that for every setting
in xterm that one user claims is wrong or breaks some application
for them, and asks me to change it to something else, that changing
that setting results in some other application breaking for some other
user in a completely different way.
It is simply not possible to have one default set of options work
for everyone everywhere in every possible situation, and any attempts
to try to improve things have resulted every single time, in making
things worse, and having more incoming bug reports - on something that
is explicitly not supported.
For example, for this specific bug report, if I were to apply your
attached patch, then I would be making bug #49315 reappear (as appears
in the comment in the file), and the solution to that recurrent
problem (bug 49315 requires that fix in place in order for
internationalization to function correctly), would be to remove your
patch. As you see, it is not possible to make a one size fits all
Any problems with the default configuration of xterm in Red Hat Linux,
users are encouraged to modify their local xterm configuration to
their own personal needs for the software mixture that they are using
in their own local environment, or alternatively to use one of the
officially supported terminal emulators.
While this is not likely the solution that you had hoped for, I hope
that I have explained the situation clearly so you can understand our
perspective on xterm related problem reports.
Thank you for your prompt response. While not the solution I hoped for, I
understand your position. I did not realize that xterm was no longer supported.
I do, however, feel the need to point out that you *are* changing the default
configuration for XTerm, by adding the fix for the super-secret bug #49315 (why
is that bug not viewable, anyway?).
No big. I've got my fix, and now I'll just maintain local XFree86 rpms so I
won't run into this again.
Yes, you are correct that the default xterm configuration that we ship
is not the stock XFree86 xterm configuration. Even though we do not
officially support xterm, as long as we do ship it, it is fairly
important that it has a mostly default configuration that is fairly
close to XFree86.org's defaults, but which is also rather sane for
various users around the world regardless of what language they use
or location they're in.
Having it only work out of the box for native English speaking users,
but be mostly broken for Chinese, Japanese, Korean, or other users
would only result in a large amount of incoming bug reports from
those users. As such, internationalization is a rather important
default setting for us to provide to Red Hat Linux users globally,
since we offer our product globally. XFree86.org's defaults, like
various other software, do not always have the best generic defaults,
and most software out there tends to favour English speakers, even
though it could come with fairly sane defaults for a wider user base.
Super secret bug #49315 is not viewable to the general public because
Red Hat developers use bugzilla to file their own personal todo items
that are not really intended for anyone else to see, sort of like
a private notepad on their desk at work, only it is in bugzilla
instead, as many of us find it easier to track certain types of todo
items using bugzilla. Also, sometimes we use bugzilla between each
other for similar todo-type things that relate between developers,
or between packages. These items are as I said, like an electronic
version of an internal memo between two developers, and while many
of them do not contain any real "super secret" information, they are
generally not of interest to the general public and are merely developers
Bugzilla is also used by other companies which Red Hat is partnered with
under contract, and bug reports may contain information which is under
non-disclosure agreement with various hardware and/or software companies.
Some bugs may contain information which includes private Red Hat information
on upcoming features that we have not publicized, or perhaps other details
that we need to discuss amongst ourselves during development or between
partners that contains private company information under NDA.
Other bugs yet, may be security related, and either filed internally,
or flagged by the reporter to be "for Red Hat development only" in order
to report and track a security issue privately. Many security issues
are reported which we are not at liberty to disclose until the date
that the reporter or some other 3rd party has set.
As you can see, bugzilla is a tool which primarily is used by Red Hat
internally for defect management, and in many cases reports may have
one reason or another for not being publically visible. I've outlined
a few of these reasons, however there are many more reasons other than
the above. Bugzilla is ultimately an internal tool, however we believe
that it benefits both Red Hat, as well as our customers and users to
make it available to the general public as well, as we do receive
a lot of valuable bug reports and feedback this way. It's easier for
us to have one single database, rather than to have multiple databases
for each different type of problem being reported or tracked, and
as such some bugs are flagged to be not visible to the general public.
Hopefully I've taken the mystery away from our super-secret bug
As a final note, since you mentioned maintaining your own rpms as a
workaround for this. Another possibility you might find perhaps even
more useful, is to create just an xterm rpm package using the upstream
xterm sources since it is maintained outside of XFree86. You could
keep it updated much easier, with your own custom defaults, and
have it install via rpm into /usr/local or /opt or somewhere and plop
in a script into /etc/profile.d that adds this directory to the path
first. Just an option I thought of which might be useful to you.
it is an internal Red Hat developer
Dang cut-n-paste blunder at the bottom of my last comment there..
Time for me to file a private bug report, to have that fixed. ;o)