Re: [PATCH] tty canonical mode: nicer erase behaviour

[zefram@fysh.org]

Pete Zaitcev <zaitcev@redhat.com> wrote:
>Rubbish. Programs get their erase characters from termios(3).

termios(3) gets its erase character from user setting via stty(1) or
tset(1), neither of which know what character will be generated by the
terminal's main backspace key.  The current situation is that the user
has to manually arrange for the correct setting.  My personal portable
shell setup, for example, contains a script that examines $TERM and sets
the tty erase character accordingly; I've never seen this functionality
available as a standard utility anywhere.

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> One of the long-standing problems preventing Unix from being a
>> user-friendly desktop OS is its handling of erase keys.  There are
>
>Not a kernel space issue

Yes, it's a wider issue, which I wanted to present as background for
the specific change I was proposing.

>                                                      Fix problem apps. 

The Linux tty canonical mode is a problem app.  Let's fix it.

Programs that talk to the tty directly, through the tty raw mode or by
any other means, do need to be fixed separately, if they exhibit the
same problem.  The patch I proposed doesn't affect them.

>They do different things, they are different keys.

On some keyboards they are different keys, and in some programs they do
different things.  Both of these are far from universal.

Programs that want to treat backspace and delete keys differently tend
to get it right already.  Under X, for example, the two keys are both
available, and are distinctly and consistently reported to the program;
many X programs implement text editing with both forward and backward
delete.  There is no problem here.

I am concerned, for the moment, with programs that only need one kind of
erase, and that talk to a physical terminal (or a simulation thereof)
via a character-stream interface.  These programs want to invoke their
backspacing erase function whenever the user presses the backspace key,
and they don't care about any other erase-related key.  Linux's tty line
discipline, in canonical mode, is such a program.

Unfortunately, the programs of which I speak can't see what key the
user is pressing, all they can see is the character that the terminal
decides to generate from the keypress.  And terminals are inconsistent
about which character they generate for the backspace key.  Even before
we look at glass ttys, we have the Linux console (with standard setup)
generating ^? for backspace, and xterm generating ^H for backspace.
Shouldn't the tty line editor work by default on these at least?  Among
glass ttys that I've personally used, the ADM3e and KDS7362 generate ^H,
and VT220 and ND120 generate ^?.

So, *for programs that only care about backspace*, by far the best
solution is to treat both ^H and ^? as backspace.  And as I said before,
the Linux tty line discipline is such a program.  Of course, we then have
the issue that the tty is already somewhat configurable in this regard,
though unfortunately not sufficiently to implement this solution.

>Erase character policy is precisely defined by posix.

It is when the IEXTEN bit is not set.  When it is set, the tty is
permitted to accept other non-standard control characters.  For example,
Linux has a WERASE (word erase) character, which is enabled only in
IEXTEN mode.

>Debian set a policy on this a long time back and have done wonders since

This is interesting.  I wasn't aware of their policy before, but I've
examined it now, after Nadav Har'El provided a URL.

Their policy appears to cover more than one related area, in an incomplete
manner.  For programs that need both forward and backward erase, it says,
basically, "programs shall make it work".  With respect to X programs,
the policy makes perfect sense and is just a statement of common sense.
For programs that interact with a tty through a character stream and
don't want to use terminfo, it insists that terminals generate ^? for
backspace, but ignores the cases where this isn't possible.

The Debian policy is a fine example of the original problem -- it shows
the hoops that people have to jump through (non-standard configuration
of xterm) to get a partial solution.

-zefram