Enter your search terms Submit search form
	Web pdp-10.trailing-edge.com

-*-Text-*-

Letter from RMS to new installations of EMACS on Twenex ("Tops-20")

Hello.  Welcome to the land of EMACS.

   So that you won't be shocked when you see it, I'll warn you before
you start that EMACS uses tons of memory (luckily, mostly shared).
An EMACS starts out with about 55K of shared memory (16K of which is
documentation that need not usually be swapped in), and about 5K of
unshared (to which the size of the files you visit will be added).
If your system provides 100 undergraduates simultaneously with the
"reasonable" response time of only five seconds of waiting after
Carriage Return is typed, then you may not want to use EMACS.
In that case, you had better erase this tape, fast, because that
experience shows that users who start using EMACS will NOT stop.
But if you use your system for program development, you will probably
find that EMACS lets you get things done faster.

   What distinguishes EMACS from the DEC-supplied editors is that it
is real-time and display-oriented: an image of what you are editing is
always visible, and changes with each character you type.  What
distinguishes EMACS from other display editors is that it is
self-documenting and extensible.  The self-documentation revolves
around the EMACS-wide "help" character, which on Twenex is Control-_.
You can type Control-_ at any time within EMACS and it will tell you
what is going on, or offer you various options for looking at the
built-in documentation text.  The extensibility is due to the
presence, within the EMACS environment itself, of an interpreter for a
reasonable (well, better than none, at least) high-level language,
TECO, which is oriented toward the writing of editing commands.

   Assuming that you have decided not to erase the tape, the first
things to look at on it are the files TWENEX.INSTALL, TECO.FILES, and
TWENEX.DIFS.  TWENEX.INSTALL contains the directions for building and
installing EMACS.  TECO.FILES tells you what each of the files on the
tape is for.  TWENEX.DIFS tells you about how your version of EMACS is
different from the ITS version.

   DON'T blindly restore all the files on the tape onto a single
directory -- their names will conflict and some will be lost!  Also,
be sure to use RESTORE *.*.* (with three stars).  If you use only two
stars, all the version numbers will be lost and replaced by 1.  If you
can create directories named <EMACS> and <INFO>, then it should work
to restore all the files on the tape under the names they were dumped
with.  If you cannot use these names, see TWENEX.INSTALL.

   On the subject of documentation, you'll see that the documentation
ranges in quality from the best to the worst.  The documentation on
EMACS itself, which is what most users will be interested in, is the
best.  New users should start off with the TEACH-EMACS program, which
lets them learn the fundamentals of EMACS by using them.  After that,
they can go to the published manual, one copy of which has been
sent with the tape, or they can use INFO to find the same information
in <INFO>EMACS.INFO.  The self-documentation in EMACS is also helpful;
it is indexed indexed by characters, command names and substrings of
command names.

  You should also have received AI memo 519a on the lessons learned
from implementing EMACS on how to go about implementing an extensible
editor.  More copies of this or the manual can be obtained from the
Publications Department of the AI lab; its address is the same as mine
except omit the room number.  The manual costs $3.25; be sure to
specify that you want the Twenex version (unless you prefer to ask for
the ITS version).

   EMACS seems to be easy for naive users to learn, and one MIT
secretary-turned-programmer says she can get new secretaries started
using EMACS in 20 minutes.  But for such results you will need an
experienced local user in addition to the documentation that we have
so far.

   You will see that there are several versions of some documentation
files.  The file EMACS.MSS is processed by the SCRIBE text justifier
to produce both EMACS.INFO and EMACS.GUIDE, in either the ITS or the
Twenex version.  SCRIBE is available from Unilogic, and is easy to
use.  Unfortunately it costs a lot of money and you don't get sources.
We are working on a clean extensible Lisp text justifier to use instead.

   As you look into the EMACS documentation, you'll see that there are
a lot of commands meant for editing Lisp code.  The popular beliefs
that Lisp is hard to read or write, or necessarily inefficient, are
just superstitions.  The support provided by EMACS overcomes the
problems of writing Lisp code, and of making it readable (the fact
that ";" starts a comment in Maclisp, as in assembler, also helps).
The inefficiency was eliminated when someone realized that there was
no reason why a Lisp compiler couldn't generate just as good code as,
say, a Fortran compiler, for things that can be expressed in Fortran.
The user is then free to enjoy all the features of Lisp which are not
shared by other languages, without any penalty.  Reasonable Lisp
implementations provide error-handling features superior to those of
most other languages, making Lisp especially suited to writing robust
system programs.

   For example, Lisp was chosen over PL/1 in writing an
EMACS-compatible editor for the Multics system, because Lisp was
easier to write, more concise, and produced better code -- in addition
to making it possible for users to customize the editor, which PL/1
would not permit.  Multics EMACS, which has transformed the way
Multics is used, is now a Honeywell product, taking Lisp out of the
Ivory Tower and establishing it as a significant force in the Real
World.  Even nonprogrammers are learning to program by writing
extensions for it.  On the MIT Artificial Intelligence Lab Lisp
machine, not only the EMACS-compatible editor but the entire operating
system from scheduler on up are written in Lisp.  I hope that in a few
years there will be a Lisp implementation of EMACS for the PDP-10,
rendering this TECO implementation obsolete.

   By the way, the Lisp-oriented commands in EMACS take up only about
one K of pure storage.  Eliminating them from your version wouldn't
save you very much.

   Those desiring to write new subsystems for EMACS should read the
internal documentation in <INFO>CONV.INFO, which is accessible through
INFO, and must also read TECORD.INFO which documents TECO.  If you
don't know TECO at all, start by reading a DEC TECO manual, and then
read TECORD.INFO because this TECO is considerably different from DEC
TECO.  The documentation for TECO is complete but very hard to read.
You should also read some of the EMACS sources, to get an idea of how
one actually writes in ITS TECO.

  At MIT, EMACS users who don't want to learn TECO but want simple
init files can get help from more experienced people.  You won't at
first have any such group of competent TECO programmers.
Unfortunately, there's not much I can do to help you grow one.  The
best I can do is to enclose a copy of some users' init files.  The
EMACS.VARS file should make it easy for nonprogrammers to do
simple customization.  You can read about EMACS.VARS in the INFO
documentation of EMACS and in the manual.

   Eventually, you will start writing new EMACS subsystems and
improvements.  Then, you should remember that EMACS is given out on a
basis of communal sharing.  One of the two conditions we place on the
distribution of EMACS is that you give back any generally useful
improvements you make to anything you get on the tape.  Just as the
rest of us shared EMACS with you, you owe it to the rest of the EMACS
community to share your improvements with us.  The other condition is
that you don't redistribute EMACS to anyone else except just as you
received it, including a copy of this letter, a copy of the manual,
and all of the files.  I would like to make sure that nobody
unknowingly receives an EMACS that is missing anything, and that
incompatible versions do not start to proliferate.  Most especially,
do NOT give out copies missing the source code!  It is very hard to
customize EMACS if you can't see the commented source of the function
you want to change.  The source code should be on line where users can
refer to it.

  TECO as distributed supports many terminal types, all implemented by
the people who wanted to use them.  If you want others, adding them is
your responsibility; then send the code back to me.  TECO is written
in the MIDAS assembler language.  Ordinary instructions are written
the same in MIDAS as in MACRO-10, but more complicated constructs are
different.  MIDAS provides more powerful macro facilities and better
error messages, as well as being many times as fast as MACRO-10.  The
documentation is in MIDAS.INFO.  Several Twenex sites have switched
from MACRO-10 to MIDAS for their assembler language programming,
because of MIDAS's advantages.  For making listings of TECO if you
change it, you will use the ATSIGN program, which is documented fully
in INFO.  ATSIGN puts on each line a cross reference (page and line
number) for an interesting symbol used on that line.  Listings made by
MIDAS itself are used only for debugging complicated macros.

   You will undoubtedly find some bugs in the version you have,
although we don't send it out with any known bugs.  When you find
them, phone me or mail to me how to reproduce them and I will TRY to
do something about them.  It will be best if you give me PRECISE,
COMPLETE directions for what characters to type in a newly-loaded
standard EMACS, with no init file, and using no pre-existing disk
files.  If you have to use disk files in the example, enclose
printouts and make them very small, so it won't be much work to type
them in.  Even so, some bugs may take considerable work to fix, and I
may not think it's worth while.  Others, I may not agree are bugs at
all.  Everyone has a different opinion about exactly how various
commands should work; that's what customization is for.  I will not
necessarily be willing to work on major projects even if I agree that
they would be worthwhile, but I would be happy to merge in your
changes if you want to write them.

   We have no distribution system set up, so we can't send updates to
everyone regularly, or whenever bugs are fixed.  We're thinking of
setting up a tape-copying tree for distribution, but that's only
speculation now.  The most I can do is suggest that every year you
send another tape and ask for the latest version.  We'll send you
another complete set of files, with no known bugs and all the latest
features.  Of course, if you want to take a more active part in
developing EMACS, you are welcome to communicate with us as often as
you like.

   Several people have asked me about converting EMACS to run on
Bottoms-10.  I can say only that it would be difficult, and the result
couldn't be made as efficient.  The difficulty, beyond rewriting all
the I/O code (which you would expect), is due to the fact that the
decoding of pointers in TECO makes assumptions about where various
spaces are arranged in memory.  Conforming to Bottoms-10's two
segments would necessitate redesigning the way pointers are decoded.
In addition, once you were done, you would find it impossible to
implement TECO's sharable library feature, on which EMACS is based.
You would have to choose a few libraries and preload them into the
EMACS high segment to get them to share, while others could be read in
by the user, but would not share.  This would mean that all libraries
could not be contiguous in memory, requiring even more changes to
TECO, EMACS, and the way EMACS libraries are formatted.  Right now,
each library contains a macro which knows that the libraries occupy
contiguous core ending at the top of the address space.  However, I
have heard a rumor that DEC will improve Bottoms-10 virtual memory so
that it will be capable of meeting TECO's needs.  Then, it will be
possible to convert TECO to run on virtual-memory Bottoms-10's with a
considerable amount of straightforward work (less, however, than was
required for bringing it up on Twenex).  I don't intend to do any of
that work, but if you are interested in it I can put you in touch with
people who share your interests.

   Once your users are all hooked on EMACS, suitability for EMACS
(which turns out to be pretty much equivalent to suitability for any
other display editor you might use or write) will start to determine
your purchases of terminals.  The minimum you need in a terminal to
use EMACS is the ability to move the cursor to any point on the screen
(not necessarily with one absolute positioning command), and the
ability to erase from the cursor position to the end of the line, and
to clear the whole screen.  If you can insert and delete lines or
characters, not only real time but CPU time performance will be
improved.   Aside from these features, which are easy to worry about,
there are the misfeatures and malfeatures which make many
almost-winning terminals useless, and they are often subtler.

   VT52's, for example, try very hard to deny the user the use of the
^S and ^Q commands.  Losing two control characters out of the limited
set which exist in ASCII can't help making it harder to edit, even if
you rearrange the command definitions so that the Search and Quote
commands can be reached some other way.  VT100's suffer from the same
problem if you use 132 columns.  I wouldn't buy such terminals if I
were you.

  Some other terminals think that the ASCII Escape character is only
useful as part of a two-character sequence, and won't let you send
just an Escape by itself.  Depending on the details of the lossage,
you may or may not be able to hide this stupidity from the user by
making TECO apply some transformation to its input.  Other terminals
store their displayed text, not as a matrix, but as a list of lists of
characters, and once a line is written with only 20 characters, it is
impossible to return to that line and write in position 21.  It may or
may not be possible to coax such a terminal into letting TECO do what
it needs to do.  The possibilities for lossage in a terminal are
endless, and there is no sure way to avoid them without actually
trying the terminal and verifying that everything can be made to work.
But one general rule is that you should not buy a terminal which is
only half-good unless it is desperately necessary.  Chances are that
you can afford only so many terminals a year, and if you buy a bad one
now you will be stuck with it for many years, instead of the good one
you could have got if you had waited a few months.  It's not as if
winning requires any great hair, which would mean extra expense.  All
it requires is the ABSENCE of misfeatures.  See the files <INFO>BSGTTF
and <INFO>TERMS.INFO.

   If you are interested in using EMACS from home over a phone line, you
should know that widespread experience with EMACS and other display
editors shows that this is possible, IF you have a 1200 baud modem and
your terminal has insert/delete line and character.  With these things,
editing can be comfortable.  Without them, it is so painful that I do
not suggest that you try it.  Getting 1200 baud may be an additional
expense, but consider it very seriously.  1200 baud modems are usually
obtained from Vadic.  As terminals with full insert and delete
capability are now selling for under a thousand dollars, there should be
no reason for getting any other kind.  In particular, buying VT-100's is
a bad idea.  If you already have VT-100's, be sure to turn off ^S/^Q
processing in setup mode before trying to use EMACS.

   The one special feature that will be of use is a "Meta" (sometimes
also known as an "Edit") key which turns on the 200 bit in an input
character.  This will enable you to type as one character many EMACS
commands which would otherwise be two-character sequences.  It won't
be standard equipment on any terminal, but the manufacturer may be
able to add it.  If you can manage to add it yourself, even, you will
find it rewarding.

   Some terminals known to win are the Ann Arbor Ambassador, the
Teleray 1061 and the Datamedia models 2500, 3025, 3052 and 4000.  All
of these can insert and delete lines and characters.  All of them are
supported.  All can be obtained with a Meta key if you ask for one.
The Ambassador is especially good because it can display 40 lines of
readable text.  The model with a meta key may not be available yet;
inquire of the manufacturer.  You can't get a Datamedia with a Meta
key from Datamedia; you must contact the distributor whose address is
in <INFO>TERMS.INFO.

   There are a few problems in Twenex that make it impossible for
EMACS to do the right thing at some times.  The file TWENEX.LOSSES
talks about them.

   EMACS was a totally unfunded project, which I worked on because I
thought it was useful.  If the administrators at the A.I. lab had been
like most of their species, they would have opposed the project,
because it wasn't funded and wasn't their idea; and if I had been like
most programmers, I would not have dared to consider disobeying.
Luckily for everyone, they aren't and I'm not, and so we have EMACS.
We'd be even luckier if the rest of the world were that way.  For
example, DEC has assembly conditionals in EXEC for multiple forking; a
super win -- if your site has bought the sources and can therefore
assemble them in.  Apparently the managers have been pressured by the
sales people not to let the feature out where the rest of you can use
it.  If the managers weren't stifling, or the programmers weren't
cowed, you would have this important feature already.  (In any case,
you have it now; look for EXEC.EXE on the tape).  Of course,
programmers in such places spend more time fighting to get permission
to do things than they spend actually doing things.  Up The
Organization, by Robert Townsend (former president of Avis), can tell
you more about this.  The Illuminatus trilogy will tell you about
Discordianism; when I heard about it, I realized that an editor which
lets each user change it around as he likes is as discordian as
software can get.

Historical note:

  PDP-10 TECO (actually, PDP-6 TECO) was originally written at the MIT
Artificial Intelligence Laboratory in 1964 by Greenblatt, Nelson and
Holloway.  Some time later, DEC took a copy, but development of TECO
at MIT did not cease.  In 1973, I added the real-time display
processor to a TECO that was already comparable to TV which DEC is
distributing now, and in 1974 I added the ability for each character
to run an arbitrary program.  Immediately, many users began to write
packages of such programs: TECMAC, RMODE, DOC, MACROS, TMACS,
Russ-mode,...  This explosion of TECO program development allowed many
ideas for useful commands and command languages to be tested.  In 1976
I started writing EMACS, which benefitted from the experiences of the
previous TECO programs.  Some of the older programs have been
supplanted entirely; some have been re-implemented as customizations
of EMACS to save their old users from having to re-learn the command
set; a couple were sufficiently different that they remain in use
today.  TECO was converted to run on Twenex by Mike McMahon of SRI (now
with MIT).

   Well, that's all I have to say, except that you should try reading
this file into an EMACS and running the M-X Dissociated Press command.
It will amuse you.

						      / 2\ 1/2
				Richard M Stallman  <  X   >
						      \  /

				MIT Artificial Intelligence Lab
				545 Technology Square
				Cambridge, MA 02139
				(617) 253-6765