github.com/PDP-10.its
1
0
Fork 0
mirror of https://github.com/PDP-10/its.git synced 2026-01-11 23:53:12 +00:00
Code Issues Releases Wiki Activity
PDP-10.its/doc/eak/emacs.lore
Lars Brinkhoff d610127777 Emacs Lore.
2018-10-23 13:30:08 +02:00

1052 lines
47 KiB
Plaintext
Executable File
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Date: 9 JUL 1978 1826-EDT
From: David A. Moon <MOON at MIT-MC>
Subject: Origins of pure-string loading
To: EMACS-HISTORY at MIT-MC
In early 1975 RMS put in EJ for RMAIL (as I recall). This allowed you to
save the impure part of a teco in a form that would execute as a program and
boot in the teco. This saved a lot of time in starting up by letting you
save a teco that had been loaded up with all the right stuff.
Sometime in the summer of 1975 the Tmacs group decided to make a sharable
library to improve paging performance, and to make a faster loader. I think
I "invented" :EJ and patched it into Teco in support of this. I'm not sure
just when this happened but I have a note from August 1975 saying a new
faster pure loading scheme was installed in Tmacs and seemed to work. I know
that the pure loader went through several iterations and changes of protocol
before it worked well.
Tmacs was unable to use EJ, because we would never agree on an initial
environment, so we couldn't use something where we had a preinitialized world
that everyone got. Each person had a different key layout and to some extent
different macros. I recall that as being one of the big things that
attracted me to Tmacs. In addition, we felt the sharing was important to get
better response because by then there were several people using Tmacs and we
considered the macros to be huge (they were maybe 8 blocks!) and the EJ
method didn't share anything other than Teco itself.

Date: 9 JUL 78 1648-EDT
From: MOON at MIT-MC
RMS@MIT-AI 07/07/78 22:25:27
To: MOON at MIT-AI
I think the cause of double-echoing YES in DIRED
is that you do MM DIRED from outside of ^R.
Yes, clearly this is the answer! I won't bother the group with another useless message.

Date: 8 JUL 1978 1345-EDT
From: Eugene C. Ciccarelli <ECC at MIT-MC>
Subject: Update to Bernie's Multics EMACS history
To: EMACS-HISTORY at MIT-MC
MC:EAK;EMACS LORE has a slightly revised version of Bernie's earlier
"Brief History of Multics EMACS" message. (The revision also written by
Bernie.) Herein follows the differences between the old and new:
;COMPARISON OF DSK:ECC;!OLD ONE AND DSK:ECC;!NEW ONE
;OPTIONS ARE /3
**** FILE DSK:ECC;!OLD ONE, 1-1 (0)
A brief history of Multics EMACS
Compiled by BSG 7/4/78
1/78 Bernie Greenberg gives 3rd rendition of SIPB Lisp Course.
Edits notes with Dan Weinreb on AI, using ITS emacs, becomes
**** FILE DSK:ECC;!NEW ONE, 1-2 (2)
A brief history of Multics EMACS
Compiled by BSG 7/4/78
1/78 Bernie Greenberg gives 3rd presentation of SIPB Lisp Course to 100
takers. Edits notes with Dan Weinreb on AI, using ITS emacs, becomes
***************
**** FILE DSK:ECC;!OLD ONE, 1-43 (1881)
~4:00 PM Greenberg decides, "you know, if we implemented that in
flat-out PL/I, we could do that even better". A little consideration
of modularity and extensibility issues soon points to Lisp as an
implementation language.
**** FILE DSK:ECC;!NEW ONE, 1-50 (2188)
~4:00 PM In a conversation to C. Frankston, Greenberg muses,
"you know, if we implemented that in flat-out PL/I, we could do that
even better".
A little consideration of modularity and extensibility soon leads to
Lisp as a chosen implementation language.
***************
**** FILE DSK:ECC;!OLD ONE, 1-57 (2682)
program (e_) could build and split lines,insert and delete characters
**** FILE DSK:ECC;!NEW ONE, 1-65 (3028)
program (e_) could build and split lines, insert and delete characters
***************
**** FILE DSK:ECC;!OLD ONE, 1-62 (2908)
A character reader is developed which allowed e_ to be driven by
reading characters ("^R mode") from the tty.
Greenberg takes over all development from this point.
**** FILE DSK:ECC;!NEW ONE, 1-70 (3255)
A character reader is developed which allows e_ to be driven by
reading characters ("^R mode") from the tty.
Greenberg takes over all development from this point.
3/5/78 (Evening)
Weinreb, having studied Ciccarelli's code, ascertains what is needed to
read single characters from Multics ArpaNET. A version of Server
Telnet is hacked up to allow programs to read single characters, and
a normal Multics process does character-input for the first time.
(Ciccarelli's technique involved special processes).
Soon, a version of the incipient editor exists which performs character
input over the network, while the normal (FNP) access paths to Multics
are limited to using Johnson's patch on the CISL machine.
***************
**** FILE DSK:ECC;!OLD ONE, 1-71 (3359)
Few understand or appreciate tehe significance.
3/6/78 (Evening)
Display support is started. Dave Moon was present at the birth of
the redisplay. The redisplay is designed to take advantage of the
explicit line structure maintained by the editor.
At first, it works only for the Delta Data 4000, but is designed so that
terminal support is substitutable.
**** FILE DSK:ECC;!NEW ONE, 1-90 (4302)
Few understand or appreciate the significance.
3/6/78 (Evening)
Display support is started. Dave Moon is present at the birth of
the redisplay. The redisplay is designed to take advantage of the
explicit line structure maintained by the editor.
At first, it supports only the Delta Data 4000, but is designed so that
terminal support is substitutable.
3/9/78
Olin Sibert hangs out at CISL all night during an intensive debugging
session of new redisplay. He develops a 2-terminal
support package that runs the display as a slave terminal. Two-terminal
use of this debugging feature becomes heavy during the next weeks,
and many falsely conclude that two terminals are necessary to use the
editor.
***************
**** FILE DSK:ECC;!OLD ONE, 1-98 (4696)
the Multics technical organization. Rather than
with shrieks of horror, the document is acclaimed, and enthusiasm for its
**** FILE DSK:ECC;!NEW ONE, 1-125 (6022)
the Multics technical organization. Rather than being meeted with
shrieks of horror, the document is acclaimed, and enthusiasm for its
***************
**** FILE DSK:ECC;!OLD ONE, 1-118 (5657)
**** FILE DSK:ECC;!NEW ONE, 1-145 (6996)
5/78 (~ 5/20)
Bill (archy) York joins CISL, becomes active editor co-developer
and development assistant, acquires skill to the point of
being able to write editor extensions in real time during demonstrations.
On 5/24, the self-documentation package, done largely by him, is
installed.
***************
**** FILE DSK:ECC;!OLD ONE, 1-165 (7822)
fortitude.
**** FILE DSK:ECC;!NEW ONE, 1-201 (9486)
fortitude, and he and Jerry Stern for implementing it.
Bill York, for contributing large amounts of time to the improvement
of this editor, and frequently pointing directions in which to go.
***************

Date: 8 JUL 78 0004-EDT
From: GLS at MIT-MC
Subject: Lisp grinder
To: EMACS-HISTORY at MIT-AI
From: RMS at MIT-AI (Richard M. Stallman)
People persist in not giving me credit for that.
GLS and I wrote it together.
That's right. I'll never forget that day. RMS and I spent
one moby hack session about ten hours long, and wrote it
essentially in one sitting. I believe the only major
correction since then has been a minor tweak involving
DEFUN syntax.
By thee way, I seem to recall having written the
directory comparator originally, but I can't remember
the circumstances. I remember it was prompted by the necessity
to maintain LISP on multiple machines.

Date: 7 JUL 1978 2223-EDT
From: RMS at MIT-AI (Richard M. Stallman)
Subject: Lisp grinder
To: EMACS-HISTORY at MIT-AI
People persist in not giving me credit for that.
GLS and I wrote it together.

Date: 7 JUL 1978 2150-EDT
From: Eugene C. Ciccarelli <ECC at MIT-MC>
Subject: TMACS within TECMAC
To: EMACS-HISTORY at MIT-MC
A glimpse into the past at a glimpse of things to come:
Late in the lives of TMACS and TECMAC, Bob Frankston decided he liked
both the TECMAC environment and the TMACS MM-command facility. I remember
him proudly showing me that the two could actually run without completely
destroying each other. (It did involve a little shuffling of some assumed
q-registers. .Q I believe was actually compatible between TMACS and
TECMAC as a q-reg name reader, but .P was a "push" subroutine in TMACS
(for pushing fs flags, filename defaults...).)I think this was some time
in '76.

Date: 7 JUL 78 2025-EDT
From: CBF at MIT-MC
Subject: Dired
To: EMACS-HISTORY at MIT-AI
I cannot for the life of me now remember whether I thought up the
Safe Dired or merely did a large rewrite of it. I am definately
responsible for having to type YES instead of Y, because I felt
Y was too easy accidentally and didn't make you think enough.
(But I don't remember the bug about reading 3 of anything, if
you didn't type N, or YES or something like ?, it reprompted.
It might have been broken though). There also was definately
a substantial rewrite within a month or two of mine by either
Moon, ECC or both..

Date: 7 JUL 1978 1055-EDT
From: John L. Kulp <JLK at MIT-MC>
Subject: TECMAC
To: EMACS-HISTORY at MIT-MC
ECC@MIT-MC 07/06/78 01:43:24 Re: TECMAC loading, documentation
To: JLK at MIT-MC
CC: EMACS-HISTORIANS at MIT-MC
Am I right in recalling that TECMAC had mechanisms for both loading macros
(by name or what? auto-loading? packages?) and for self-documentation?
Or, what was the documentation facility like?
TECMAC could only load a whole macro file (not individual macros). Since there
were no named strings or q-regs in those days, you could only load into ^R
slots or q-regs. The obvious disadvantages of this scheme for people who
only wanted to use one or two macros, was one of the points which strongly
motivated the development of EMACS and pure string librarys.
There was a self-documentation feature (which obviously only needed to work
on q-regs and ^R macro slots and ^X,^Y etc) which was driven off of documentation
files (i.e. they were more like MM TECDOC - the documentation was not in
core as it is in EMACS). ^X? and ^Y?, ^L?, ^W? all did the obvious things.
There was also an M.D macro for doc on q-regs, etc.

Date: 7 JUL 1978 1048-EDT
From: John L. Kulp <JLK at MIT-MC>
Subject: TECMAC
To: EMACS-HISTORY at MIT-MC
RE the start of TECMAC, at the time that RMS put the feature into TECO
to allow ^R characters to be defined, he came by to talk to RLB and I
about making a macro package which made use of this feature. Within a
week or two of the release of this TECO, we had hacked up some macros
which just resided in our init files. I don't remember too clearly
exactly how long it was before we started puting hairy commands in
and hacked the loader, but I think the ^X and ^Y scheme was in there
from the beginning.

Date: 7 JUL 1978 1034-EDT
From: John L. Kulp <JLK at MIT-MC>
Subject: Minibuffer, Incremental Search
To: EMACS-HISTORY at MIT-MC
cc: RLB at MIT-MC
Minibuffer: I believe this idea originated with RLB (although RMS was also in
on the eary discussions of this idea so I'm not sure who really thought of
it first). RLB made the first implementation, which was pretty rudimentary.
I fixed it so that it did not cause so much redisplay and added a number
of other features (window expansion, recursive ^R indicators, saving the old
minibuffer, quiting, no display when  is typed ahead,etc.).
In EMACS, RMS added the idea of a minibuffer ring.
Many original uses for the minibuffer have been made obsolete by & READ LINE.
Its main use these days is for TECO programmers who want to get a temporary
TECO environment to write a quick macro or investigate the state of some
variables, etc.
Re Incremental Search. I think (but I could be wrong) that this idea originated
with RMS. RLB and I at various times grossly rehacked the first quicky
implementation, and it was rehacked again completely upon transferal to EMACS.
Some other ideas due to RLB: the ^M macro which moves over blank lines
when possible rather than inserting new ones; treating CRLF as a single char
to ^D and RUBOUT, ^K not deleting the CRLF, the argument accelerator (^T in
old TECMAC).
I'm not sure where the invention of ^V came from or the mark stack. Many of
these things got implemented by a number of us sitting around bs'ing about
what features would be a win, and then someone of us would go implement it.
RG suggested the old ^X^@ and ^Y^@ commands for saving and restoring point
from a q-register.
Another idea generated by GLS and RLB was auto-fill mode for LISP. It didn't
work terrifically (except when typing in new code) and was never revived in
its original form.
GLS (mostly) wrote the LISP grinder in TECMAC (now also in EMACS). CFFK wrote
the MACSYMA grinder in TECMAC/EMACS.
GLS originated the MM COMPARE DIRECTORIES macro in TECMAC, which was grossly
rehacked by RMS in EMACS (??)
RLB thought up and implemented the loader format for the old TECMAC.
I think that RLB was the first person to come up with the rotated directory
display (and also the first implementation).
I implemented ^A, ^E, ^N, ^P to move on screen lines.
RLB and I originiated the EDIT ..D macro.
I am not sure how we arrived at the ^L, ^W, ^X, ^Y prefix scheme for old TECMAC
(for LISP, WORD, put and yank(get)).
Old TECMAC had some very primitive editing modes (LISP and WORD) which primarily
redefined ^I and ^J.
Well, enough for now. If I feel like flaming again some time, I'll send more.
If anyone is interested, there are old TECMAC files on the datacomputer
<<<ITS>EEPLASMA>TECMAC

Date: 7 JUL 1978 0511-EDT
From: MOON at MIT-AI (David A. Moon)
Subject: Disorganized Ramblings
To: EMACS-HISTORY at MIT-AI
By the way, the "feature" where the yes answer to DIRED echos both at the
top and the bottom of the screen still sometimes happens. I've never figured
out the circumstances, but I have seen it happen. ECC's original misfeature
that you have to type 3 characters (if this first isn't N or X) before it checks
whether it is "yes" and if not tells you you are a loser is still there also;
I guess nobody worries about these things too much. In fact there is still
more old TMACS (and TECMAC?) code in EMACS than you might expect; i.e. 6 or 7
functions.
By the way, no one has mentioned the fact that "TMACS" is relatively recent.
For many years Earl's/Eugene's editor (with Charles and me as more or less active
hangers-on) had no name. I guess it got a name when we started talking about
it to other people.
Also deserving to be mentioned are that there are still at least a few people
who maintain their own completely private editors, not based on anyone else's stuff.
Such things have often been a source of inspiration to the public editors (and vice
versa.) "Diversity is a good in itself" ?

Date: 7 JUL 1978 0309-EDT
From: Eugene C. Ciccarelli <ECC at MIT-MC>
Subject: The 3rd DIRED
To: EMACS-HISTORY at MIT-MC
What the hell -- I'll get in on this too if I can...
After either CBF or Moon (whichever or both) added the "safety" to
DIRED (keeping a list of files to delete, listing them, and asking for
confirmation), I got my grubby hands on it. As you "deleted" files with
^K, the screen would delete the line containing the file so you always saw
what the directory was going to look like (assuming you later gave
confirmation for the deletes). This had two problems for me: first, I
have a terrible memory and couldn't keep track of what was being deleted
and whether I really wanted that -- until the last minute when I was given
the list; second, the redisplay was unbearable at 1200 baud (which is
what we were subjected to); and third (...), I believe there was no way
to undelete files in the delete-list. (Can't remember that last quite so
well -- maybe I hadn't considered it.)
My contribution then was to minimize redisplay and confusion by having
^K just put a "D" at the beginning of the file's line. Perhaps there was
an undelete at this time, or perhaps one just deleted the "D" by hand
(after all, it WAS a ^R mode).
----------------------------------
As a sidelight, here, just so I don't appear too coherent: The "yes"
typed by the user in response to DIRED's delete-query was echoed both at
the bottom of the screen and up where the query was printed. This cute
feature was unfortunately later lost, probably due to some Teco change or
something.

Date: 6 JUL 1978 1628-EDT
From: Guy L. Steele, Jr. <GLS at MIT-MC>
Subject: the birth of EMACS
To: EMACS-HISTORY at MIT-MC
The account of my involvement given by RMS is essentially
accurate. I started ? because I was getting tired of the kludginess
of the TCMAC command arrangement, and saw in other editors neat commands
that could not be fit cleanly into TECMAC. I therefore decided to
perform a total reorganization of the command structure, and carefully
examine all the other existing TECO-based editors, such as RMODE,
DOC, and the ever-popular TMACS. Most of my work involved playing
with assignments of commands to keys, and running around organizing
discussions and soliciting comments. I made an initial stab at a loader,
and I think I invented (or re-invented) the notion of a compressing
loader, and invented most of the specific conventions for the EMACS
loader (such as using _ for a space), though these conventions were
greatly refined later. It was at about this point that RMS and others took
over the development work, and did a much better job, much faster,
than I could have. For this reason, as well as the pressure of classes
and the maintenance of LISP, I was happy to let others take over ?.
Thus, while I provided initial impetus and much of the original
user-level command structure, most of the development work and succeeding
refinements is to the credit of other people.
The name "?" was chosen not only because it was hard to type to DDT
(one could win with 1'? ), and so would force a more rational choice
of name later, but also because the initial work was by Quux (GLS),
strongly influenced by Moon, hence Quux/Moon => QM => Question Mark.

Date: 6 JUL 1978 0513-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject: The 1st DIRED
To: EMACS-HISTORY at MIT-MC
I believe I wrote the very first version of DIRED for TMACS. The basic
assumption was that if ^R mode was a winning way to edit your programs, then
it might win for editing (i.e. deleting files from) your directory.
So, MM Diredfoo; put you in a recursive ^R mode displaying directory
foo. The ^K command in this ^R mode was hacked to not only delete the line
from the screen, but also to delete the file named on that line. I don't
believe there were any other commands. After trying it out for a while I
was convinced it was a win and released it to the rest of TMACS. I think
almost everyone's response was "how dangerous", i.e. with a single keystroke
you could mistakenly delete a file (or several because <arg>^K worked!). It
was used in its initial form for a while, but then some safety minded person
(Moon, or perhaps CBF?) changed to save a list of the ^K'd files and then ask
for confirmation on exiting.

Date: 6 JUL 1978 0334-EDT
From: RMS at MIT-AI (Richard M. Stallman)
Subject: RMAIL
To: emacs-history at MIT-MC
RMAIL appears to have started in early '75.

Date: 6 JUL 1978 0315-EDT
From: RMS at MIT-AI (Richard M. Stallman)
Subject: ^T mode
To: emacs-history at MIT-MC
TECO ^T mode existed when I got here in '71, I think.
If not, then certainly before the time when in the summer
of '72 I started working on TECO. It was still being used
by somebody on printing terminals when I fixed it.

Date: 6 JUL 1978 0311-EDT
From: RMS at MIT-AI (Richard M. Stallman)
Subject: :EJ and loading
To: emacs-history at MIT-MC
I seem to remember that :EJ antedated EMACS by at least
half a year. I remember talking to someone (EAK, I think)
about conventions for the TMACS loader macro. At that time,
the state of TECO was such that block-loading offered a
considerable speed advantage, so the convention was oriented
toward that. A list of macros and q-registers or ^R characters
for them to go in was put in the buffer, and the loader macro
for each file processed and deleted those it could handle,
passing the rest to the next file. At the birth of EMACS I
added a bunch of TECO features to make the lookup of names
faster, and these had the effect of removing any advantage
from block loading. Also, making MM commands use the same
loader macro, and the desire to be able to use it to
call subroutines, meant that single macro loading had to be
convenient and efficient. So I decided to change the
loader macro conventions. But it was a hard decision, because
I had already put the TMACS conventions into TECO ORDER
with the intention that many people could build libraries
in different ways as long as they conformed to the same
convention. And here I was planning to make libraries and
not adhere to it. Luckily, I decided to change it anyway.
At first, I made the loader macro use the new variants of
the O command which I put in for that purpose. About this time,
O commands started ignoring case, and became able to abbreviate.
I also made the O command smart about skipping text with no "!"'s in
it. I had a loader macro which contained a large number of tags, each
tag being followed by the relative index of the corresponding macro
and a ^\.
But after EMACS reached about a sixth of its present size
(containing more than a sixth as many macros, since a lot of
small ones were written first), that was no good, because
the O already took too long. Since the table was full of tags,
the hack of skipping non-tag text fast wasn't buying much.
At first I tried renaming macros so that subroutines would
come at the front, MM commands next, and ^R commands (looked up
only in init files, and mostly not at all after the dumped
EMACS was built) last. That's why subroutines are named
starting with "&", except for a few that go in q-registers
and don't need to be fast to look up with MM, which therefore
have names starting with "^^".
Soon that wasn't enough either. It was taking just
about forever to set up the default environment, and
looking up a documentation macro (way at the end) would
take 200ms. So I frantically wrote the FO binary search
command and switched over to using that.
The hack of having variables named MM ... to replace
commands was invented by somebody else; I can't remember who.
I think he also wrote the first MM Compile One.
By the way, the TMACS "purify string" hack, used to run RMAIL
under TMACS, really horrified me because the purified string
was not in standard TMACS loader format and would make the
loader macro unusable.

Date: 6 Jul 78 0251-EDT
From: RMS at MIT-AI
Subject: word abbrevs
To: emacs-history at MIT-MC
I think word abbrevs started because ECC talked to me
about either some TECO features he wanted to facilitate
writing his "abbrevs", or exactly how to make something
happen in ^R, or something, and I assumed he meant word abbrevs.
After he enlightened me that they were character abbrevs,
I started urging him to do word abbrevs as well.

Date: 6 Jul 78 0246-EDT
From: RMS at MIT-AI
To: emacs-history at MIT-MC
I think that a "q-register loading macro" was one of the first
things implemented in every macro package.
I know that MACROS and RMODE had them all along.
I think they antedated ^R.
I am not actually very sure why they were needed, since
they offered only cosmetic improvement over the ^:I command
(until documentation began to be handled).

Date: 6 JUL 1978 0240-EDT
From: RMS at MIT-AI (Richard M. Stallman)
Subject: the birth of EMACS and its naming
To: EMACS-HISTORY at MIT-MC
1) The name "?" was adopted, as far as I know, only because
nobody had any good idea of a name to use. This case of
dumb-striking was much more severe than usual. So all we
could think of was "?" for "I don't know what it will nbe called".
2) The name E was chosen because I saw that E was one of the remaining
single-letters left which didn't traditionally abbreviate anything.
From E, EMACS followed. That it might confuse Stanford people
was a bonus but not the fundamental motivation. In part, another
motivation was the desire not to use "T", because of the desire
to emphasize that the user would NOT be using TECO.
3) The work done by GLS was
a) to consider a large number of possible command sets, and
suggest many interesting possible commands, and
b) to begin doing actual work (on the purifier and
start-up). Although none of this code survived
after a week or so, I might never have been able
to start doing anything if left to myself.
I often have trouble getting off the ground.
4) I'm not really sure why GLS stopped working on EMACS.
I think he was too busy with class-related things, or some
such. I had expected him to stay interested.
5) The first thing done in EMACS was the support software.
The purifier, the loader macro scheme, the scheme for
dumping an EMACS so that it could start up fast, and
the self-documentation, were finished before there were
any editing commands. I think this has helped bring about
the quality of the self-documentation.
6) I do remember that :EJ was patched in by some TMACS
person before I heard about it.
7) Most of the theory behind EMACS comes from TMACS,
rather than TECMAC. From TECMAC come only individual
commands. I guess that the ^X prefix character is from
TECMAC also, but I'm surprised to hear that there was
any macro package which didn't have prefixes.
8) The first ^R-macro written was an auto-fill space.
It was my example of what could be done with such.
I wrote it just after implementing redefinable characters.
9) I think that RMAIL is important, because it was the
first demonstration that a reliable system program could
be written in TECO, and the first example of one that was
invoked other than by running TECO and typing TECO commands.
I was able to document it without mentioning TECO at all until
the place at the end where I mentioned the Altmode command.
10) When I first heard about TMACS, I assumed that the MM commands
and the ^R commands were the same. When I found out that they
used two separate mechanisms, I was amazed. Making those two
be uniform was one of the primary initial goals of ?, which
was going to do in a reasonable fashion what TMACS had explored
with kludges. EMACS is full of kludges inside, but they
are hidden away inside of Generate Library and EINIT.

Date: 6 JUL 1978 0219-EDT
From: Charles Frankston <CBF at MIT-MC>
Subject: self-documentation in Tmacs
To: Emacs-Historectemy
I really find it hard to keep these mailing lists straight.
TMACS did have documentation, and it evolved in this order:
The original MM macro had MM INFO which listed all of the
macros followed by the first line of explanation and 1 MM INFO
followed by a string argument, which would print the whole
doc for that macro. After Tmacs also started keeping a
library of ^R commands (and first started being called Tmacs)
the ^R commands did not have any form of documentation,
which was considered a deficiency. Late in Tmacs life,
I implemented a documentation scheme for the ^R keys also.
I believe this was after Tmacs was already a pure string,
and following Moon's advice, I began the documentation
with ~DOC~ since ~ would be sorted to the end of the
string file and could therefore be paged out better.
(I don't know if people remember how bad a problem the
memory required by the editor was, but it wasn't for
idle experimentation that Tmacs started hacking pure
strings, and remember the AI machine had 256K). I believe
then MM DOC printined out info on ^R commands and could
be made to prompt for a key to document or take the long
name of the command as the string arguement. Something to
note is that some command such as the Word Macro repeated
their documentation internally because it was so slow
(especially in terms of paging) to call MM DOC on itself!
I think the same ~DOC~ scheme was initally used by ? macros,
until the long name ^R mode and MM macros evolved to use
the same source and documentation conventions. I believe
RMS was repsonsible for them developing to this point, and
it was probably GLS who stayed with using the Tmacs scheme
for expediency to get the editor up.

Date: 6 JUL 1978 0150-EDT
From: Eugene C. Ciccarelli <ECC at MIT-MC>
Subject: MM Info
To: EMACS-HISTORY at MIT-MC
In early TMACS MM days, there was self-documentation for MM commands.
(Not for ^R commands.) MM Info would allow a few different forms. If
called as MM Info$mm-name$, it looked at qreg M, scanned down til it found
the start of the code for mm-name, and then printed the documentation it
found there (I think a comment right after the MM-name label). If called
as just MM Info$$ I believe it described all MM-commands. If MM Info were
given several string arguments it described each of those MM commands.
Shortly after the birth of MM Info$, MM BInfo$ appeared, which would
briefly describe (first documentation line) all MM commands or those
mentioned in string arguments.

Date: 5 JUL 1978 0201-EDT
From: Charles Frankston <CBF at MIT-MC>
Subject: timing..
To: ECC at MIT-MC, EMACS-HISTORIANS at MIT-MC
Were the TECMAC people really hacking the same time we came up with MM..
As I remember the chronology, you started hacking MM the summer
of 1973. I started using it around September. We didn't discover
^R mode for a couple of months after that, so I don't think the TECMAC
stuff had started yet..

Date: 6 JUL 1978 0050-EDT
From: Eugene C. Ciccarelli <ECC at MIT-MC>
Subject: The Multics line editor "terminal_"
To: EMACS-HISTORY at MIT-MC
Just a couple of notes concerning the "terminal_" program, which
Bernie mentioned:
Originally Doug Wells concocted terminal_ to show some ARPA people
that it was possible to have a stripped-down process wake on each
character coming in from the net. The idea was that they might have some
supervisor (kernel) process provide echoing, similar to what the FNP did.
Next, Bob Frankston put in a couple of control-characters, like ^A for
sending a quit, and perhaps rubout processing, and started using it across
machines, CISL to MIT., as a regular front-end. I think it kept a few
statistics like run time, cost, memory.
Next, I think in 76-77, I started adding features to it to make it be
a line editor, somewhat based on what I'd heard about the Stanford one,
and using functions close to Teco ^R mode ones that acted within a line.
I found this front end functionally preferable to any other I knew for
Multics (including TELNETing from ITS) and used it for most of my Multics
hacking. Luckily I did such hacking at night usually; terminal_ wasn't
grossly expensive compared to the regular process (it ran about the same
cost when the regualr wasn't doing much of anything), but the response was
unbearable with over 40 users or so.
Finally, as a prototype/hack, Charlie Davis and I tried a two-process
display editor using terminal_, partly for easy fun hacking, partly to
have the first Multics display editor (but not necessarily use it...), and
partly to see what kinds of problems distributing the editing might bring.
A couple of capabilities were added to terminal_, primarily the ability
for the regular process to tell terminal_ to break on given characters and
send what it had edited so far for the line, and also to load the line
buffer with given text for editing. The regular user process ran a bunch
of (Multics...) Teco macros, collectively referred to as "Perch" (PER
CHaracter). Perch would keep track of the screen, perform inter-line
operations, and load/read terminal_'s line buffer. terminal_ would edit
and display within one line. The result looked like a raw Teco ^R mode
and wasn't unimpressive (again, under 40 users) except for the many bugs
which were never worked out since it wasn't written for using really...
I think Perch was born in about a weekend's time or so. The date was some
time last summer I think. At latest, last fall.

Date: 5 JUL 1978 1404-EDT
From: John L. Kulp <JLK at MIT-MC>
To: EMACS-HISTORY at MIT-MC
cc: HENRY at MIT-AI
An interesting point of history: Henry Lieberman @AI hacked the original
LISP indent macro which was used in TECMAC (where it was improved somewhat).
I don't know if any implementation preceeded his. He used it even before
^R mode as M.H in his init (I think). The current generation of LISP indenters
have little resemblence to these old ones (partly because of TECO knowing about
LISP syntax), but the concept was back then.

Date: 4 Jul 78 2126-EDT
From: DLW at MIT-AI
Subject: The name of Emacs
To: Emacs-History at MIT-MC
I specifically remember having an XFILE to change
the name of my editor job to "?", which looked interesting
on the Name Dragon display. What I remember about the name "E":
When one did a FINGER at SU-AI, one most often saw a lot of people
running a program named "E", which was their editor. RMS told
me that he wanted to fake them out by having everyone HERE running
something called "E" ("Gee, are those MIT people running our editor?"),
and that the name "EMACS" was an afterthought to justify the short
name "E".
I also remember that in the early days, the MM @ Teco macro
was regularly used to make listings of EMACS. Apparently once
EMACS got going, it was so good that it obviated the need for listings
of itself at all!

Date: 4 Jul 78 2106-EDT
From: MOON at MIT-AI
Subject: The birth of Emacs
To: Emacs-History at MIT-MC
In August 1976, a bunch of hackers decided it was time to write a new
editor, using the sharable-library and named-commands (MM) technology
developed by Tmacs, but intended for general use. Tmacs was not really
set up to be used by anyone but its maintainers, and I think every user had
a different set of key bindings, although by that time it was in use
by perhaps eight or ten people. The new editor, which was initially called
"?" because that was a command name which could not be typed to DDT, was
supposed to take full advantage of the TV keyboards, to have a more sensible
and consistent set of commands, to have good self-documentation,
and to be faster than Tecmac. ? was intended to woo people away from Tecmac.
The initial work, up to the point of a semi-usable system, was done by GLS.
Later, RMS got interested in his indefatigible fashion, put in a large number
of features, and made Teco changes to greatly increase the efficiency and
flavorfulness. The editor was renamed to Emacs (abbreviated E) in imitation
of the name of the Stanford editor, which it otherwise does not resemble.

Date: 07/06/78 1821-edt
From: Greenberg at MIT-Multics
To: ecc at MIT-MC
Re: \440
A brief history of Multics EMACS
Compiled by BSG 7/4/78
1/78 Bernie Greenberg gives 3rd presentation of SIPB Lisp Course to 100
takers. Edits notes with Dan Weinreb on AI, using ITS emacs, becomes
convinced that this is the way to go.
2/78
A discussion group "Multics Editor People" is formed, debating
whether or not Multics ever could support a real time editor,
and debating various degrees of distribution of the editing
task between central system and terminals. The opposing
views held by the Elder and Younger Frankston brothers
becomes a lively feature; some, pointing to the work of Ciccarelli,
who developed a video-oriented character-at-a-time line editor for
Network use on Multics, begin to feel that the
only way to investigate the situation is to construct such an editor.
2/78 Greenberg expresses views about editors and TV's to Larry Johnson,
Multics Communications expert ("FNPmeister"), who asks for a
demonstration. One is scheduled.
3/3/78
1:00 PM. A Demonstration of ITS EMACS is held on the CISL Delta
Data 4000. MC system is used, under heavy load, at 300 baud.
Lack of organization, lack of preparation, hardware problems, low speed,
load, and other difficulties contribute to an almost totally ineffective
presentation. Some, however, were impressed. C. Frankston,
E. Killian, E. Ciccarelli, and others participated.
~3:00 PM. Larry Johnson was impressed. He says, "We should be able to
do that", and devises a FNP (communications processor) patch that
enables character-at-a-time input on Multics. C. Frankston witnesses
this.
~4:00 PM In a conversation to C. Frankston, Greenberg muses,
"you know, if we implemented that in flat-out PL/I, we could do that
even better".
A little consideration of modularity and extensibility soon leads to
Lisp as a chosen implementation language.
~6:00 PM SIPB Friday Night dinner is eaten at Colleen's. Various
parties throw around ideas about right way to implement such an editor
on Multics. The ideas of Bruce Edwards, who had recently implemented
an editor in Lisp, stand out as important.
~10:00 PM C. Frankston drives Edwards and Greenberg to
Brookline, in heavy snow. Edwards visits Greenberg's apartment
(he lives down the block). They log in, and two hours, some beer
and tty paper later, a functional editor in Lisp exists. This
program (e_) could build and split lines, insert and delete characters
and lines, and move its pointer about. It has no display or
other output capability, and is driven by calls to Lisp functions.
3/4/78
A character reader is developed which allows e_ to be driven by
reading characters ("^R mode") from the tty.
Greenberg takes over all development from this point.
3/5/78 (Evening)
Weinreb, having studied Ciccarelli's code, ascretains what is needed to
read single characters from Multics ArpaNET. A version of Server
Telnet is hacked up to allow programs to read single characters, and
a normal Multics process does character-input for the first time.
(Ciccarelli's technique involved special processes).
Soon, a version of the incipient editor exists which performs character
input over the network, while the normal (FNP) access paths to Multics
are limited to using Johnson's patch on the CISL machine.
3/6/78 (Morning)
The software constructed that weekend is run on the
CISL development machine, printing out via debugging
functions, displaying a cursor as <>, but interacting
character-at-a-time via a reconstruction of Johnson's patch.
Few understand or appreciate the significance.
3/6/78 (Evening)
Display support is started. Dave Moon is present at the birth of
the redisplay. The redisplay is designed to take advantage of the
explicit line structure maintained by the editor.
At first, it supports only the Delta Data 4000, but is designed so that
terminal support is substitutable.
3/9/78
Olin Sibert hangs out at CISL all night during an intensive debugging
session of new redisplay. He develops a 2-terminal
support package that runs the display as a slave terminal. Two-terminal
use of this debugging feature becomes heavy during the next weeks,
and many falsely conclude that two terminals are necessary to use the
editor.
3/27/78
A mailing list of users of the Multics Editor is formed by
Earl Killian. Killian, an avid supporter from the beginning, provides
many good ideas and illuminations of "why ITS did it this or that way".
Killian constructs, with Greenberg, a DataMedia 2500 control package,
allowing ITS users to use the editor via a feature in ITS user
telnet. Use from ITS becomes regular.
People at MIT begin using editor via the ARPANET, which
supports character-at-a-time interaction.
4/13/78
Greenberg writes and promulgates, officially, a Honeywell
Multics Technical Bulletin proposing that Multics EMACS, as he now
calls it, be shipped as part of Multics. Containing scathing
denunciations of Multics communications support and existant editors,
and proposing the support and distribution of Lisp as
part of the deal, the document is distributed throughout
the Multics technical organization. Rather than being meeted with
shrieks of horror, the document is acclaimed, and enthusiasm for its
ideas shown by all concerned.
4/19 (Evening)
Two-window mode is implemented. The first of several "hairy features"
of note, this feature had a birth of fire, killing people's Lisps
and processes for a few days before it stabilized. Richard Lamson,
of IPC, becomes a regular user, and subjects himself to buggy software
and new features. His detailed comments and accurate reporting
lead to rapid development.
4/25/78
A Multics Change Request is submitted by Larry Johnson
proposing a "new teletype mode to break on every character" for the
explicit reason of "support of Bernie's editor". Proposed as
an experimental feature, "breakall mode" passes through the
Change Review Board with only 1 dissenting vote, an issue of
documentation.
5/78 (~ 5/20)
Bill (archy) York joins CISL, becomes active editor co-developer
and development assistant, acquires skill to the point of
being able to write editor extensions in real time during demonstrations.
On 5/24, the self-documentation package, done largely by him, is
installed.
5/28
PL/I mode is implemented, comprising logic which parses all
PL/I statements, using algorithms from the compiler. The most
significant in a series of optional "packages", which included
console-message processing and automatic declaration, this package
signifies the kind of feature indicating the editor reaching maturity.
By this time, at least a dozen terminals are supported. EMACS
gets production use on the CISL machine. People in Phoenix play
with it regularly.
6/26/78
Greenberg and Weinreb design and implement the "Youngers
of Zion" ARPANET protocol, a variant of SUPDUP in which most
screen management is done by the user telnet process. Multics
EMACS becomes totally effective on ITS TV's, and potentially usable
from any ITS terminal.
6/29/78
Enough support for "breakall" mode to allow it to be used without
patches is installed on MIT Multics. Lamson and Gary Palter use it
for the first time via dialup lines to MIT in character-response mode,
and note excellent performance under normal midday load. Although
response is excellent, resource consumption of the editor appears to
be a large problem.
-------------------------------------------------------
I MUST THANK:
Richard Stallman, for Perpetrating ITS EMACS upon the world, and
promulgating the EMACS philosophies, most significantly, the
separation of Editing and Programming languages in an editor.
Earl Killian, for seeing this thing through every step of the way and
guiding it
John Gintell, my boss, and HISI, for allowing me to work on it all!
Bruce Edwards, for the day when editor caro factus erat,
Dave Moon and Eugene Ciccarelli, for many incisive and straightforward
comments as Multics EMACS grew and misgrew.
Richard Lamson and Gary Palter for submitting themselves to my software
regularly, and giving accurate bug reports.
Larry Johnson, Fnpmeister, for inventing and implementing breakall mode,
and expressing an interest in the entire issue with increasing
fortitude, and he and Jerry Stern for implementing it.
Bill York, for contributing large amounts of time to the improvement
of this editor, and frequently pointing directions in which to go.
Dan Weinreb, perpetrator of EINE, for help all along and all
kinds of support.
Charles Frankston and all the people at SIPB for violent and
powerful support throughout.

Date: 4 Jul 78 1727-EDT
From: RMS at MIT-AI
To: EMACS-HISTORY at MIT-MC
No specific people gave me ideas from any other display editors.
I have taken ideas from them, but it was always based on simply
seeing them in use. I was influenced heavily in writing ^R mode
by using E at SAIL (in fact, I started writing it when I was there).
These influences were as to the general manner of operation;
the specific commands I took at first from CMM's previous ^R mode
which had been implemented in '72 (I think). I read the E manual
a few times to look for useful commands to put into EMACS,
and also when I wrote the INFO tutorial. INFO itself was somewhat
based on what I learned about NLS from some documentation I got.

Date: 4 JUL 1978 1712-EDT
From: Eugene C. Ciccarelli <ECC at MIT-MC>
Subject: More on the 1st MM, ^R, o^]
To: EMACS-HISTORY at MIT-MC
Date: 07/04/78 17:02:44
From: RMS@MIT-AI
To: emacs-historians at MIT-MC
Re: A couple of comments on the "origins of MM"
1) ^R mode was started in Sept. '73, and didn't have redefinable
characters for about a year. So the statement about when TECMAC
was defining prefix characters must be wrong. I am not sure whether
TECMAC even existed before ^R mode.
2) The reason why O^]^X$ wouldn't work was that it was that TECO
knew that the jump-cache mechanism would screw it up, and didn't allow it.
Eventually I made TECO smart enough to detect that a ^] had been used
and just not cache that particular jump.
I have been watching EMACS LORE eagerly ever since its inception
hoping to see all sorts of neat stuff. Let's get going.
Note that such contributions should go to EMACS-HISTORY.

Date: 2 JUL 1978 1637-EDT
From: Eugene C. Ciccarelli <ECC at MIT-MC>
Subject: The 1st MM
To: EMACS-HISTORIANS at MIT-MC
Here's something about the early days of MM:
When CBF and I started working at 2-366 in the summer of '73, we
conjured up a "moby macro" and stuck it on q-register M. (M, I think,
because it was simplest to type two of the same character, and because it
was mnemonic as an extension of Teco's M.) The idea was suggested to
me by CBF, who was thinking of the Multics Teco practice of having
EM-files (external macros, several in one segment). (How did they branch
to the right macro? By name of the segment used in the EM, so all macros
would have their names added to the segment?) He basically wanted to call
things by a name rather than one letter, as well as try to keep track of
lots of macros. I think then that we were probably solving this
keep-track problem about the same time (or later) than the TECMAC people
with their ^R prefix-solution, but we were unaware of their approach.
The first MM had a few Teco problems to contend with: Teco didn't
have multiple or even virtual buffers, and I had not yet learned the
clever trick of using . and z-. to bound a changing part of the buffer;
also, more seriously, Teco wouldn't "correctly" execute: O^]^X$ or O^]q$
to branch through a "variable". (A problem of context levels: while s^]
would work, o^] would push all the label definitions, and thus get an
"Unseen go-tag" error.) MM was born before this problem was fixed: it
would pull a copy of itself into the buffer (knowing it was in M), search
for something at the top like "o**LABEL**" (I forget exactly what) and
replace it with the actual string-argument label. Then it would stick the
modified version of M into q-register T and macro that.
Since the first MM was thus saving the buffer before doing its
M-machinations (hxS to be specific...), restoring it just before calling
T, and the o<lable>$ took time proportional to the offset in M of the
<label>, as what we were editing (the ROUNDHouse operating system) grew
and the number of macros in M grew -- the thing became verrrry slow.
(This was on a ML, not MC.) We started dividing the MM-macros into two
groups: general ones, and ROUNDH-specific ones, the latter going into the
son of M, N. However, the father outlived the son...

Reference in New Issue View Git Blame Copy Permalink