new xterm and erase setting
Mike A. Harris
mharris at www.linux.org.uk
Sat Jul 3 01:04:06 UTC 2004
On Wed, 30 Jun 2004, Harry Putnam wrote:
>>> I'v very certain I wasn't getting the respective behavior in emacs or
>>> less prior to this change.
>> If you mean the 'backspace' key worked with the old version - then yes
>> - I can reproduce this.
>> I have some xterms which I didn't kill after installing the new
>> version - so I'm able to comapre (old and new behavior). I also have
>> an FC2 box - with 179-6.EL - where I can reproduce the old behavior.
>Maybe Mike will wake up and tell us what he changed ... : )
No problem. ;o)
Red Hat previously applied a custom patch to the xterm resources
file that ships with xterm. Every change that Red Hat has ever
made to the xterm resources does two things:
1) It fixes some problem or improves xterm in some way for
2) It changes xterm from the upstream default, and causes
behaviour differences for people who expect the xterm default
behaviour. Some of the changes make life very easy for the
average PC using xterm user, but make things more difficult for
the average old school UNIX user, using a highly heterogenous
UNIX environment, with Red Hat OS's connecting to non-Linux OS's,
using software such as Hummingbird Exceed, etc.
In general, almost every possible "bug fix" for xterm, fixes one
users problem and creates a problem for another user. In other
words, it is generally impossible to make xterm work by default
for everyone out there in every situation. Different users
simply require different application defaults, and there is an
extremely large number of users out there with very different
expectations for how things should work out of the box.
That means it is basically impossible to make everyone happy, yet
we still need to have a "default". Our defaults are generally
chosen so that things work best for the largest group of users
out there, however that is still a complicated problem to choose
The closer we stick to upstream xterm resources, the better, as
any problems encountered by people are generic xterm issues.
However, there are certain things that xterm defaults to, which
are extremely inconvenient for the userbase using our operating
system. One example of this, is that the average person using an
IBM PC or similar computer, or using some other architecture
with a PC keyboard, is used to the "backspace" key deleting the
character to the left of the cursor, and the "DEL" key deleting
the character under the cursor. That is traditional PC keyboard
behaviour, and what the overwhelming majority of all computer
users expect to happen. It is for this reason, that this is our
intentional desired default handling of both of these keys.
Old school UNIX people however, may very well be used to UNIX
terminals or other keyboards which the meaning of these keys is
It's essentially impossible to have a single default work for
both groups of people, and it is a heavily debated topic out
there. The important thing is to _have_ a default, and generally
speaking, default configurations for computer software should
really reflect what the largest group of users of the software
expect to be the common behaviour. Since the xterm defaults do
not reflect the behaviour of what the majority of users expect,
we have to customize the default xterm configuration to make
things work like most users expect. The side effect of this, is
that users prefering traditional UNIX behaviour, or using
software such as Exceed, may need to customize their xterm
resources manually to get a configuration that works within their
Over time, we've gained a number of such divergences from the
upstream xterm resources. The xterm 191-1 package no longer has
any Red Hat customizations - it is stock xterm with no resource
modifications. So anything that is now "broken" in the eyes of a
user, is "broken" so to speak in the default upstream xterm -
where "broken" is of course entirely within the eyes of the
beholder, and will vary from person to person.
The purpose of the exercise, was to see just what default xterm
resources people consider "broken", and to re-enable the Red Hat
customizations for those issues where deemed necessary. If any
of our customizations aren't missed, we can possibly drop them,
and the closer we are to upstream xterm, the less maintenance
overhead there is, as well as the less problems the upstream
maintainer of xterm will see from Red Hat OS users
So far the experiment has went well, and I've got a list of
things that I plan on re-enabling soon.
Thanks again to everyone who has tested xterm and posted back to
the list their experience and feedback!
More information about the test