"Valeriy E. Ushakov" <uwe@stderr.spb.ru> writes:

> On Thu, May 03, 2007 at 10:56:07 -0400, Greg Troxel wrote:
>
>> "Valeriy E. Ushakov" <uwe@stderr.spb.ru> writes:
>> 
>> > mowestusa <mowestusa@yahoo.com> wrote:
>> >
>> > I think you are confused.  "delete-right" or "delete-left" are actions
>> > that program performs in response to certain key presses (in the case
>> > of terminal - bytes coming from the tty).  Of course you was able to
>> > "delete-right", it all about how your programs are configured.
>> 
>> Sure, but I think the point is that the behavior of DEL was wired into
>> the cooked-mode tty processing, and most programs used cooked mode.
>
> Wired?  Even in V7 you certainly could control it, and defaults still
> were '#' for erase and '@' for kill (I've just verified that with simh
> and, my, it took me some time to remember how to boot it :).

Sorry, speaking loosely.  I meant that the notion that there was some
character that would remove the last character from the cooked-mode
buffer and either output BS SPACE BS to clear it, or some sort of \e
(were it e) and then  \e when you typed e so you'd get "ce\e\at", or
something that I don't remember very well after 30 years.   Everyone in
the group had set erase to ^? as soon as we had CRTs, and thus I didn't
remember that #@ was still the default.

>> While you could certainly delete the character at the cursor in vi or
>> emacs, that was about those programs interpreting some key sequence that
>> way, as opposed to now where nearly all X11 programs interpret the
>> "Delete" key as delete right.
>
> And just what is "delete-right" in the cooked (aka "canonical") mode? ;)

Indeed, there is no function for it, and there was no standard key.

> Terminals used to be independent devices that sent bytes to the host,
> usually using serial line.  That's reflected in the tty(4) model.
> There are no "key presses" (or key releases) in that model.
>
> Terminal emulators (xterm or kernel console driver) usually receive
> key presses/releases and emulate terminal "send sequence of bytes"
> behaviour to support tty(4) model.  As emulators are configurable, you
> can make them send whatever you want, emulating different terminals.
>
> You can use stty(1) to set tty(4) VERASE to the char that the driver
> will treat as "delete-left" (and as explained above, there's no
> "delete-right" in this model).
>
> Smart programs that provide advanced editing usually use TERM
> environment variable to look up terminal description in the termcap
> (or terminfo) database.  Thus they can recognize sequences of bytes
> sent by the terminal and convert them back to "key presses" (though
> there are no key releases in this model).  Thus a program can see
> three bytes \E[D and recognize them as "left arrow key".  Often such
> programs use curses library instead of messing with termcap themselves
> or readline that messes with termcap for them.

I agree, but I'd say that the escape sequences are converted into
"logical keystrokes" that have no direct single-character ASCII
equivalent.  This dates from the early days of CRTs where the VT52, and
more famously the VT100, on which the ANSI terminal standard is based,
sent sequences beginning with ESC for arrow keys.

> Termcap has "kb" capability for the sequence of bytes sent by the <-
> aka <X] aka BackSpace key and "kD" for the sequence sent by Del.  Most
> programs also check the VERASE setting and use it to mean <- as well.
>
> Emacs is a notable exception that doesn't rely on curses for
> converting sequences of bytes into keypresses.  Emacs uses its own
> database (in form of lisp files in its lisp/term directory with
> keybindings for different terminals).
>
> In principle, you shouldn't care about what character your <- send,
> b/c programs should pick it up from VERASE and termcap.  But I guess
> it's emacs ruins this idyllic picture (no offense, I'm a long time
> emacs user myself).  Having originated in the DEC-orieneted world
> (where <X] sends DEL), emacs uses BS (^H) for help.  Of course on a
> terminal that sends BS for <- that causes a lot of grief.  Thus emacs
> users tend to stick with DEC ways and make their <- keys send DEL.
>
> On the other side there are various programs (e.g. various kinds of
> firmware) that hardcode ^H as their "delete-left" character.  In rare
> cases when I need to deal with them, I don't mind using <Ctrl>+<H>
> chord, but I guess people that deal with them often (and don't use
> emacs :) think otherwise and like their <- to send BS.

Yes, this is the unresolved culture clash, and not likely to be
resolved.  The basic issue, as you point out, is that programs from both
worlds need to work.

> All this boils down to:
>
> . what does your terminal sends
>
> . what is your stty setting for VERASE (for programs that rely on tty
>   driver canonical input processing)
>
> . what is your TERM (for "smart" programs)
>
> and you want the three to be in sync.

And that this needs to get propagated consistently on remote login.

> Since wscons "vt100" emulation really emulates vt220'ish terminal, it
> makes sense to keep 14 (<- or <X] or BackSpace) mapped to Delete
> (generating DEL) and 211 to KP_Delete (generating \033[3~).
>
> The first one matches default VERASE 0177, so default mapping matches
> default stty settings.  The latter is already described by kD=\E[3~ in
> termcap descriptions of vt220 &co, so it should do the right thing and
> provide working "delete-right" out of the box.
>
> There's still consistency issue - USB keyboards generate BS for <- and
> xterm defaults favor BS too.  I'm not sure how to deal with this
> sanely (I whacked xterm into never ever giving me ^H unless I press
> ^H, and I rarely use USB keyboards for console) but it's been like
> that for ages and the above proposal doesn't change it, so we can
> probably ignore it for now or spin that off into a separate
> discussion.

I am afraid that it's not possible to "fix" this in a way that makes
everyone happy.  I am in favor of making things behave like the old
days....

> PS: FreeBSD made an interesing hack, they've added VERASE2 char and
> they set it to BS by default.  Thus tty(4) "just works" with either BS
> or DEL.  On the other hand you need to teach every program that deals
> with tty(4) that VERASE2 exists.

Hmm, that seems messy.

> PPS: Sorry if the above sounds like rambling.  It's kinda hard to
> squeeze the long story into a few paragraphs, especially since I
> haven't used some of the systems/terminals for quite some time, so my
> memory is patchy.

No problem.  Isn't an occasional trip down memory lane part of the
NetBSD mission statement :-) ?