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 
   certain users.

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 
defaults for.

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 
somewhat different.

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 
environment.


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 
(theoretically).

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 mailing list