% -*-LaTeX-*- % 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.