kdch1 is \177
kbs is ^H

That hasn't changed in ncurses or xterm for several years.

No, in all my Fedore Core 1 & 2 installations kbs=\177 and kdch1 is
the usual escape sequence. In all Fedoras, kdch1=\E[3~. Check it out:

infocmp xterm | grep kdch1

Right about kdch1,
wrong about kbs (if you're seeing it as anything but ^H,
that's a Redhat customization - I'm reporting what ncurses
and xterm have in the change history).

With FC3 RH decided to drop all RH customizations from ncurses and
xterm. Which on itself was a good thing todo.

But this has created this problem, as T.E. Dickey has written upstream
ncurses and xterm have used ^H for backspace for years.

Somewhere in the 5.x/6.x days RedHat decided to follow the Debian
keyboard guidelines which say, that backspace should always send
ASCII-del (\177), this was and is a Debian custimazation and not
something done upstream. Note the decission to follow the Debian
keyboard guidelines was partially made under my influence as I was a
betateam member at that time and have done a lot of testing and
patches to get consistent keyboard behaviour in textmode.

After this bit of history on to the current problem. As reported
ncurses now contains the upstream default of ^H for backspace, but the
terminal used by the reporter sends ASCII-del. This means that the
reporter is not using xterm as xterm shipped with FC3 uses the
upstream default of ^H, but is probably using gnome-terminal or
konsole since these both send ASCII-del for backspace.

So the question is does RedHat still want to follow the debian
keyboard guidelines for backspace in which case xterm and ncurses need
patching, or does RedHat wants to use the upstream defaults for
ncurses and "the real" xterm and patch gnome-terminal(libvte) and
konsole to match the real xterm. I believe to remember a mail by
someone at RedHat which said that RH still wants to follow the Debian
keyb guidelines (Havill?), but I've also heared sounds that RH wants
to stick to the upstream ncurses and real xterm and fix gnome-terminal
and konsole, the latter seems to be the final conclusions of the
discussions under bug 122815.

Assuming that RH wants todo the latter (unmodified ncurses, make
backspace send ^H) I've entered two bugs to fix konsole and
gnome-terminal a long time ago:
http://bugzilla.gnome.org/show_bug.cgi?id=157448
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138191

If RH however decides to follow the debian keyb-guidelines then this
bug is valid and a bug for "the real" xterm needs to be opened.

Peter (Rockai), this bug has been open since 12-11 and yet nothing has
been done, could you please discuss this internally in RH (Havill?)
and get a decission on wether RH is going to return to following the
Debian keyb guidelines, or is going to stick with the official ncurses
way (backspace = ^H).

Fixing this is easy once the decission has been made! If the decission
has been made I'm more then willing to write up all needed patches to
fix this, iow I'll hand you the solution on a silver platter, but we
need a decission first!

Note: as the concensus above concludes delete is not a problem.

yes - it's awkward for me to change things like that,
since (for example), the same definitions would ultimately
apply to FreeBSD, which uses ^H.

mharris,

I asked for help for the resolution of this bug on #fedora-devel, and
twaugh responded that you might know what todo, so I'm adding you the
the CC-list of this bug.

The big question which stops this bug and a number of others of
getting resolved is what character should the backspace key in a
terminal claiming to be xterm send, ASCII-DEL or CTRL-H . T.E. Dickey
the upstream ncurses (terminfo) and "the real' xterm maintainer says
that it officially has been CTRL-H for ages and doesn't want to change
this, but in the past RH has shipped patched versions which make xterm
& friends send ASCII-DEL, following the debian keyboard guidelines.

In FC3 things are a mess and I would like this issue decided upon so I
can check all involved packages and get them consistent (as decided)
for FC4.

Thanks!

>So the question is does RedHat still want to follow the debian
>keyboard guidelines for backspace

Yes.  The changes we previously made to xterm resources for this, were
disabled when we disabled our resources patch.  The intention was to
find out which of the changes were still really necessary, and to
clean things up a bit, however due to time and resource constraints,
xterm ended up not getting this patch re-enabled for quite some time.

xterm in rawhide now once again has our resources patch enabled, and
it has been tidied up a bit.  We've removed things that we used to
patch for that upstream xterm now has defaults that are the same or
close enough.

While it is definitely a very widly debated issue as to how the BS
and DEL keys should work, I take the position that both groups are
correct.  That is to say that Backspace should work on an IBM PC
keyboard, like users used to using IBM PC keyboards with other operating
systems such as Windows and DOS, are used to Backspace working, which
is to delete the previous character and move back one position, and
the DEL key, on an IBM PC keyboard, should keep the cursor where it
is, deleting the character under it, and pulling characters after it
towards it.

If that sounds confusing at all, I can simplify it by saying that
BS key should work like it does in Microsoft Windows, and DEL should
work as it does in Windows also.

The reason for this decision, is that while both ways are "correct"
depending on what type of keyboard you are using, and what computing
background you are coming from, there can only be one single default.

The user who does not know the difference, or even realize that there
are different ways that BS and DEL might work historically on different
computer systems, generally is going to be used to the Windows/DOS way
that these keys work, and is not going to be comfortable with trying
to reconfigure their system to do what they think it should do by default.

Old school UNIX users, and others who are used to VAX terminals and other
terminals however are much more likely to understand the intricacies
of configuring this low level stuff, and are in a much better position
to be able to understand the available options in the various different
pieces of the puzzle, and to configure their system to work the way
they are used to for UNIX historical or other purposes.

So, the simple acid test is to install Fedora Core on a traditional IBM
PC with a PC keyboard and normal standard off the shelf Walmart computer
hardware basically, open a terminal on it, and type something.  Press
backspace and it should work like it does in Windows, press DEL and it
should work like it does in Windows.  If it does not, that is a bug, and
we want to change it to make sure it does work like it does in Windows.

As I mentioned above, I realize that some people's preferences are
very much different from what our goal here is.  Since it is not possible
to have it both ways, a decision must be made as to how we want these
keys to work in our OS, and we've decided that, and hope that everything
works consistently throughout the OS with this stated goal.  I believe
this is part of the logic behind Debian's decision as well.

Hope this helps clarify and understand the problem from our angle.

>hardware basically, open a terminal on it, and type something.  Press
>backspace and it should work like it does in Windows, press DEL and it
>should work like it does in Windows.  If it does not, that is a bug, and

This is a tough problem. Years and years of similar issues have caused every
application to apply a number of workarounds and patches. By now it is almost
impossible to foresee (even with a correct setup!) what will happen.

What I can tell for certain is the ne (the nice editor) does it in the right
way, and does not try to make guesses. If it is set up correctly, it will work
with ne.

The only important thing, however, is that the terminal database agrees with the
keys emitted by the terminal. The rest will follow (or you can complain mightly
with whoever wrote the application 8^).

Harris,

Thanks for taking a look at this and for the answer. I fully understand and
agree that the keys should behave as under windows. But I wonder what is your
answer, since you started your answer with:


>So the question is does RedHat still want to follow the debian
>keyboard guidelines for backspace

Yes.....

So was that a Yes as in Yes this is the question and then the long story to
explain that there isn't an easy answer? Or Yes as in "Yes, RH still wants to
follow the Debian keyboard guidelines"

As explained I've currently been working on making konsole and gnome-terminal
behave as the real xterm does, since that is what the claim to be, but this 
is NOT according to the Debian keyboard guidelines.

Your whole explanation that the keys should behave as under windows is 100%
correct and agreed upon, but doesn't help us to answer the question. For these
keys to behave correct a couple of things are nescesarry:
-terminfo and the terminal should agree on the sequences send by the keys
-stty erase should be set to the sequence send by the backspace key
-the application should either properly use terminfo (Note: dumb applications
(f.e. less) will work fine as long as stty erase is ok)

The first 2 criteria are what the discussion is about now, and as long as things
match it can be either way and things will work as you (we) want. Combining this
with the upstream upstream manta and Thomas E. Dickey's (upstream) clear vision
on this I personally prefer ditching the debian keyb guidelines, following
upstream xterm and ncurses(terminfo) and make xterm wannabees behave as the real
one does.

The answer is basically that Red Hat wants to have what we had from about
Red Hat Linux 5.0 or so onward to Fedora Core 1 or thereabouts, which
is I believe in line with Debian guidelines.  Our xterm is now doing
exactly what it was doing before.  If anything else in the mudpie
has changed in any way from what it was before, it needs to change
back, or otherwise bend and fit the common goal.

What I want to totally avoid in the process, is receiving a stream of
bug reports from people because something has changed and they don't
like having to adjust to the change.  That is why our xterm is using
what it has always before.  I will do whatever I can to avoid a
maintenance or support nightmare.

Our konsole and gnome-term maintainers hopefully will keep those
terminals working similarly, however I'm not involved with maintaining
those, so I don't really have much of an opinion about them.

If by "upstream mantra" you are refering to my statements from before
about wanting to keep xterm as close to upstream defaults as possible,
perhaps I should clarify things a bit...

gnome-term is our official "supported" terminal application, with
"konsole" being second.  "xterm" is provided more or less as-is, as
many people are used to it and prefer it for historical reasons, or
prefer its lower memory footprint, or have some other preferential
reason for wanting to use xterm instead of our supported terminals.
There are enough xterm users out there that the application is
definitely quite relevant, and probably will be for quite some time.

We prefer to focus our engineering resources on a smaller set of
applications as that gives the biggest bang for the engineering
buck.  As such, we've been trimming the OS each release for some
time now, to try to reduce the amount of duplicated functionality.

Dividing our engineering resources between 3, 4, and sometimes 5
or more applications (such as email clients) all of which serve
the same purpose, but differ in feature sets and specific functionality
spreads our engineering resources thin, which results in smaller
overall progress each OS release.  The idea here, is by concentrating
effort on a smaller set of applications, we get more overall
progress each release.

Some of the applications, such as xterm, which provide duplicate
functionality however, are very widely used, and so dropping them
from the OS just because they're not the officially supported
terminal application would have too major an impact to the OS for
many people who are used to it.  We therefore include xterm in
a more or less "as-is" state to minimize engineering and support
overhead, but we balance that by providing occasional upstream
bug fixes and other updates as time permits.  This seems to be
a healthy way of letting people have their cake and eating it
too in practice, but without tying up much engineering time.

What I found, was that a lot of the bug reports we were getting
before, weren't bugs in xterm at all, but were feature requests
from people for us to change the default of some option or another,
and when we changed that, someone else would file a bug report
that it broke something else.  Juggling options seems to be
a fine art of selecting one desired behaviour for one person,
and creating an undesired behaviour for another person.

I decided that our goals should be, roughly in order:

1) Make our default out of the box configuration/operation work like
   the majority of users expect.  Assume a PC style keyboard, and that
   "general case" means "person familiar with how the keyboard works
   in Microsoft Windows".

2) Keep the defaults for as many things as possible, as close to the
   upstream sources as possible, to minimize the likelyhood of a Red Hat
   specific change creating a problem for someone, as that would increase
   the amount of manpower we might need to dedicate to resolving the
   problem in what is an "as-is" rpm package.

So, while we want to remain as close to upstream as possible, we will
still change things from upstream defaults wherever it makes sense
to do so to minimize the number of bug reports received.  Generally
that means making things work like Windows users expect as far as the
keyboard workings, but there are a few other changes we need as well.

Some of our changes have been removed over time as upstream xterm
has changed defaults over time to match, or something else has changed
in a way that solves the problem in a different way.  ie: the scrollback
buffer size change - that wasn't as big as the buffer we used to provide
by default, but it was much larger than the previous default, and a
fairly good compromise, so we dropped patching for that.

I hope this explanation helps to understand some of the resource changes
we apply currently.  The #1 goal is to receive as close to zero bug
reports from people as possible, and when we do receive bug reports,
and fixing one of them creates another one, the goal becomes to fix
the problem that affects the most people and would thus theoretically
generate the most bug reports.  That's a fairly sane goal IMHO.  ;o)

In general, we meet this goal I believe, although the last OS release
or so our xterm was missing a few things due to lack of time to spend
on it, but it's now back to where it should be I believe, and aside
from people prefering different default configuration options, the
upstream xterm maintainer Thomas Dickey does a pretty good job at
fixing any real "bugs" that people discover.

Hope this clarifies things a bit more.

Thanks.

Ok.

So Debian keyboard guidelines it is. IOW backspace for terminals claiming to be
xterm should send ASCII-DEL aka \177. This has the following concequences:

- This bug report is valid for both FC3, FC4test2 & rawhide, IOW
ncurses(terminfo)'s xterm alias should be patched so that kbs=\177. Please
change the status of this bug to assigned, I'll attach a patch shortly.
- XTerm needs part of the old app-defaults patches reapplied so that it to sends
\177 for backspace instead of ^H . I'll create a patch and a bug report for this.
- Parts of a patch I've submitted to konsole (in FC4test2) which amongst other
things changes backspace from \177 -> ^H need to be reversed. I'll take care of
this.

Created attachment 113282 [details]
patch fixing this 'bug"

As promised a patch fixing this "bug".

A patch fixing this has been attached, please fix this before FC4test3, aka
freeze moment so that this will be fixed in FC4.

Applied, commited & built. Thanks.