Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!boulder!sunybcs!rutgers!ucla-cs!zen!ucbvax!LF-SERVER-2.BBN.COM!jr
From: jr@LF-SERVER-2.BBN.COM (John Robinson)
Newsgroups: comp.emacs
Subject: Re: gnumacs bindings
Message-ID: <8709181552.AA11597@ucbvax.Berkeley.EDU>
Date: Fri, 18-Sep-87 11:52:40 EDT
Article-I.D.: ucbvax.8709181552.AA11597
Posted: Fri Sep 18 11:52:40 1987
Date-Received: Sun, 20-Sep-87 03:04:46 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: jr@ALEXANDER.BBN.COM
Organization: The ARPA Internet
Lines: 78

>> It seems to me that this "cultural river" is relative.  Emacs started on a
>> system which used DELete to mean just that (and most of the terminals had a
>> nice DELete key!).

Before ASCII, DELETE was called RUBOUT (I'm talking about the teletype
model 33, folks), which seems even better of a description.  DELETE
sems to have no directionality to it (to me), whereas rubout seems
more to refer to something that was just typed.

>>  Some(how,when) Unix(tm) picked (first "#" and then)
>> BACKspace to mean delete.  (I assume some Unix guru's keyboard didn't have
>> a decent DELete key?)  Now Emacs runs on Unix systems, and Unix users are
>> used to BACKspace.

Well, Unix history is even more arcane than this.

In V7 (my history only goes that far), # meant delete-char and DEL
meant interrupt (really!).  This was a problem, because DEL was often
a nice big fat key - too easy to hit - and also users coming from
other worlds (i.e. DEC-10 and -11) were fond of hitting it to mean
delete-char, and had awful trouble when learning to use Unix.
Fortunately, it was possible to remap this function to something they
were used to, like ^C, but many people kept delete for it anyway.

At about this time (early-mid-70s), people still largely used
teletypes and other printing terminals for timesharing systems.  The #
as an erase character was okay, since you could see how many you had
typed on the print line.  Unix was still too small (i.e. ran on too
small machines) to consider the fancy sort of line editing it now
supports.

Also, about this time, people began to use CRT terminals.  On a crt,
it was handy to be able to have the line contining the cursor look
like what the program was going to get.  This was never possible for a
printing terminal (without going to a new line), but almost any crt
could do it roughly this way: use BACKSPCE (BS) as your delete-char!
As you delete typed-in characters, the cursor moves backwards over
them.  As you retype over your mistakes, the new echos overwrite on
the same line the deleted characters.  What you see is *mostly* what
you get (exceptions - the new line is shorter than the original, or
else some characters cause no cursor movement when echoed, but are
still deleted by BACKSPACE, so you get confused about where you are
versus what's in the type-in bufer).  Note that this also can be used
for printing terminals, but you won't necessarily be able to read the
result.  And, most important, the Unix terminal driver didn't need to
change at all; it just happened magically since the delete-char was
always simply echoed back to the terminal when typed.

Next came kernel support for crts.  The simplest version is to echo
the sequence BS-SPC-BS whenever the delete character (whatever its
value) is typed.  Now the deleted characters are removed from the
screen as they are deleted (overwritten by spaces - no help for
printing temrinals of course).  With more cleverness, the terminal
handler can cope with characters that don't take up space, or take up
two spaces (control characters echoed with ^ first).  Now, the user
has no particular *cute* mapping to be preferred for delete-char, but
BS may have persisted anyway.  I realize that 90% of the audience may
have met Unix since it grew reasonable terminal-handling, but try to
imagine that it used not to be able to afford the memory for it.

Note that this kernel support was often added as a local enhancement
before it found its way into the supported Unix versions.  As such,
there were probably a lot of other variations on what I described
(which matches what happened at BBN), some of which may have become
quite popular before being supplanted by a "standard" implementation
from Bell or Berkeley.  By now, the standard version is powerful
enough to emulate just about any local variant, which of course also
fosters a lot of diversity.  So there is no single most-common choice
for how the delete-char function is mapped in the Unix world today,
and the standards in other worlds add even more diversity that people
can opt for by customizing their terminal parameters.  And then there
are the shells with built-in comand line editors (tcsh or bsh, if you
have heard of them), but that's another story.

... those that fail to learn from history are ... etc.

/jr
jr@bbn.com or jr@bbn.uucp