% -*-LaTeX-*-
% <BEEBE.EPSILON>TECOWHY.LTX.4, 27-May-86 17:49:38, Edit by BEEBE
% This is part of TECO.LTX

  There are two fundamental differences between \TECO{} and almost
all other text editors:
  \begin{itemize}
 \item \TECO{} is a complete programming language, containing the
       three necessary  constructs---sequential execution, repetitive
       execution, and conditional execution---which have been
       mathematically proven sufficient to write any program.
 \item Because \TECO{} can access the {\em values} of characters,
       it can be used for context-sensitive editing which is utterly
       impossible without this ability.
  \end{itemize}
Although reasonable text editors generally provide some sort of
shorthand for repetitive editing tasks through keyboard macro
definitions, and some allow commands to be given numeric arguments to
be used as repeat counts, this functionality alone is insufficient
for many editing tasks, because it lacks conditional execution.

A simple example relevant to \FORTRAN{} programming might be {\em
find the next line in the edit buffer which is longer than 72
characters}.  Since the \FORTRAN{} language ignores text beyond
column 72, and does not require explicit declarations of variables,
long lines which are unlikely to be recognized as such on typical
80-column terminal screens can introduce insidious program bugs
which will never be detected by the compiler, and probably not by the
programmer.   An editor lacking the ability to scan forward in the
buffer computing line lengths and stop when the length exceeds
the specified limit simply cannot help here; conditional execution is
essential.

The previous example did not require the editor to have knowledge of
{\em what} characters were being processed, only the ability to
{\em count} them and
determine line lengths.\footnote{Remember that not all computer
systems use an actual character as an end-of-line marker.} As a
second example, therefore, consider the task of automatically
changing the case of letters in a portion of text.  This might be
done by a text replacement function which all editors offer, but it
would likely be painful.  If the requirements were tightened so that
this substitution should happen only on text in certain columns of
each line, or on words following a backslash, then it might well
become impossible, except by tedious manual deletion-insertion
editing of every such instance.  Humans should not have to do this,
because it is boring, repetitive, and likely to introduce many
new errors.

  A programmable text editor, like \TECO{}, can handle tasks
like this with very little effort, and although it may take a few
tries to get the \TECO{} program working correctly, it can perform
its job on an arbitrarily large amount of text.

  You may of course argue (correctly) that you can write a program
for the task in your favorite language, and after a few trips round
the compile--link--debug cycle, get it to work on the text.  It will
almost certainly take {\em you} much longer to do this than if you
could write it in \TECO{}, and except in \LISP{} environments, you
probably had to exit and reenter your text editor many times.

Even if you are fluent in \LISP{}, and have one of the \EMACS{}
descendants built on top of it, you will type many fewer characters
to do the job with \TECO{} than with \LISP{}.  On the other hand, if
you are building up large libraries of editing functions to be used
many times, it will be easier to read and understand your \LISP{}
code  than it will if the code is in \TECO{}, particularly
uncommented \TECO{}.   I therefore feel that there is a place for
both high- and low-level languages for editor extensibility.

 The beauty of \LISP{} and \TECO{} is that their uniform syntax makes
it possible to implement  rudimentary versions  of interpreters or
compilers for the languages with very little work, compared to that
required for a more conventional computer language like \C{}.  For
example, the first working prototype of this \TECO{} interpreter took
two days and two evenings to get to a state where most of the
planned functionality was finished and working well enough to be used
to help develop itself.  This was done without reference to any
\TECO{} manuals or other documentation, just sitting creating the
code on the fly inside \EPSILON{} on an \IBMPC{}.  If this interpreter
were now to be moved to another system, it could probably be done in
half the time.
