Re: delete key funny character

[David Holland <dholland-tech%netbsd.org@localhost>]

On Fri, May 13, 2016 at 06:41:41PM -0400, firecrow silvernight wrote:
 > im having an isaue in xterm where the delete key shows ^? instead of normal
 > behavior.

The "delete" key (labeled "Del" or "Delete" on conventional keyboards)
or the "backspace" key (usually labeled "backspace" or "<-")?

If the backspace key, the way to deal with this in xterm is to use the
ctrl-leftmouse menu to change the setting of "Backarrow key
(BS/DEL)". This controls whether the backspace key sends backspace
(^H) or delete (^?). If the delete key, use the same menu to change
the setting of "Delete is DEL"; this controls whether the delete key
issues delete (^?) or an escape sequence, apparently "\1b[3~".

There is an endemic problem in Unix where the "erase" or "backspace"
character understood by software can be either backspace or delete,
and various combinations of keyboards, terminals, and software running
on terminals do and don't do the right thing when you press the
backspace key. As collateral damage this also means that sometimes the
wrong thing happens when you press the delete key.

The reason for this is that historically in Unix the erase character
was delete (^?). (Unless perhaps if you go way, way back...) The
reason for this is that delete is 0x7f, and the reason delete is 0x7f
is that on a paper tape (yes, a paper tape) if you type the wrong
character you can always eliminate it by punching all the holes; hence
all bits set; hence (in a 7-bit environment) 0x7f. This then stuck.
This character is also sometimes (now mostly historically) called
"rubout".

The rest of the world moved on from teletypes in the late 70s and
early 80s, and so in e.g. the MS-DOS world the backarrow or backspace
key always produced the backspace character, and the delete character
was used for deleting to the right. But of course Unix did not manage
to move on from teletypes, and still hasn't. So there was software
that expected backspace and software that expected delete, and both
usually did the wrong thing if the other character was typed. At one
point Sun made keyboards with two backarrow keys in the upper right,
one that produced backspace and one that produced delete; thus you
could theoretically always use the right one for whatever software you
were using.

In the 90s there was an effort to deal with this issue and get rid of
the use of ^?, but it didn't fully take and problems still remain. And
nobody's done anything much since.

Nowadays most programs transparently accept both ^H and ^? to mean
"backspace". This includes basically everything that does its own
input handling, except for Emacs, because in Emacs control-H had long
meant "help" and RMS was unwilling to change this just because the
overwhelming majority of the world had been using control-H to mean
something else for 15+ years. (I think he may have finally given in.)

Programs that just use the tty driver cooked mode for input, like what
you get if you run "cat" and type into it, can be configured to accept
either ^H or ^? via the utility stty(1), which adjusts tty driver
settings... but not both. Except that I think in NetBSD the tty driver
now accepts both anyway.

The result of this though is that without intervention the "delete"
key backspaces instead of deleting from the right, so at some point it
got changed (at least in xterm) to issue an escape sequence instead so
applications could detect this and interpret it as intended. But this
also has to be configurable, so we end up with the mess you've
stumbled into where there are four settings and any particular piece
of software might demand one or another to work the way you expect.
Plus the settings can be changed by accident (either by accidentally
invoking the menu, or by command-line arguments, or by X resources, or
i think even by sending escape codes to the tty) so you can end up in
a confusing broken state without realizing it.

The whole situation with keyboard handling in Unix is highly
unsatisfactory. This is only the most overt aspect of the problem.

-- 
David A. Holland
dholland%netbsd.org@localhost