|
Variants Although the term TECO once referred to a lineage of text editors originally written for DEC minicomputers by DanMurphy and subsequently worked on by MIT students, it has grown to encompass a variety of editors using the same commands. The TECO family, so to speak, spans innumerable programming languages, paradigms, and computer architectures. Aside from the original version in PDP machine code, a few notable examples are: TecoC? - If the TECO family has a "standard", this is probably it. TecoC? conforms to the original TECO manual---nothing more, nothing less. It was written in C (to be compatible with everything from Raspberry Pi to PCs and Cray supercomputers) by Pete Siemsen, and later added to by Tom Almy and Blake McBride?. Latest source available at https://github.com/blakemcbride/TECOC. Binaries (for a slightly older version) available at http://almy.us/teco.html. The source, if compiled, has a video mode; al VideoTECO? - This was the original attempt to write a TECO with |
The central concept of TECO as a programming language is wonderful: it’s geared towards processing text by repeatedly finding text that matches a given pattern, taking a given action when it finds it, and then selecting the next pattern to look for. That’s a very natural, easy to understand way of writing programs to do text processing. TECO also does well as a vanilla text editor: every command (i.e. verb) is one character long, with appropriate numeric (i.e. adverb) and string (i.e. noun) arguments before and after respectively.
TECO is one of the most influential pieces of software ever written. If, by chance, you’ve ever heard of a little editor called EMACS---well, that was originally a set of editor macros for TECO (EMACS = Editor MACroS?).
Unfortunately, TECO has a reputation for clobbering documents should one not have mastered it fully. The most common reason given is the fact that its commands are all one character long, and that TECO syntax therefore looks like random line noise. A quick thought experiment will show that this is a gross oversimplification. Vi and Vim also have one-character commands, yet they can be learned within a day. The true reason is that until recently, no readily-available TECO had a visible text buffer (like Vi does), and of those that did (for DEC and HP mainframes), no TECO had a text buffer that updated in real time. To update the text buffer, one pressed Escape twice (which would execute all the commands "lined up"), and if there was a single error in the queue, well, tough luck.
Although the term TECO once referred to a lineage of text editors originally written for DEC minicomputers by DanMurphy and subsequently worked on by MIT students, it has grown to encompass a variety of editors using the same commands. The TECO family, so to speak, spans innumerable programming languages, paradigms, and computer architectures. Aside from the original version in PDP machine code, a few notable examples are:
TecoC? - If the TECO family has a "standard", this is probably it. TecoC? conforms to the original TECO manual---nothing more, nothing less. It was written in C (to be compatible with everything from Raspberry Pi to PCs and Cray supercomputers) by Pete Siemsen, and later added to by Tom Almy and Blake McBride?. Latest source available at https://github.com/blakemcbride/TECOC. Binaries (for a slightly older version) available at http://almy.us/teco.html. The source, if compiled, has a video mode; al
VideoTECO? - This was the original attempt to write a TECO with
A TECO has the following features:
History
Back in the years when the squishy chair in the Oval Office was warmed by the adipose derriere of one L.B.J., the text editor available on M.I.T.'s DEC PDP-1 (an early model of minicomputer) was called Expensive Typewriter. This editor justly deserved its name; it lacked even a search option or the ability to go backwards through one's document, and at the time, the operating system on the PDP-1 supported a single user. The only way to edit on the computer, then, inherently wasted very expensive time on an activity that could be done elsewhere far more profitably.
It should be noted here that IBM mainframes used stacks of punched cards to store documents, while DEC minis used a paper tape. All the text editors to come would emulate one of the two experiences. Punched cards held one line of 80 characters each and could be shuffled, inserted, and deleted at will---this is the same paradigm as is used by line editors. Tape, on the other hand, held a stream of any number of characters, but because a stream of tape has no line numbers or indeed lines, editing locations needed to be specified by location from the "top" (problematic for the user) or by context. In addition, if an error were found, the entire tape would have to be re-punched or cut-and-spliced---and splicing was difficult.
The confluence of these two Bad Things was even Worse. And so, TECO was born. TECO was the “Tape Editor and COrrector”: it was a Turing-complete programming language in which you could write programs to make your corrections. With TECO, it was easy to specify a context, search for it, and optionally move y positions up or down. Branches, looping, and conditionals (of which Turing-completeness is a side effect) added descriptive power to searches---on which TECO depends---so naturally, they were added.
Instead of editing "expensively", Dan Murphy hoped, you’d first examine the faulty text and prepare a TECO program "off-line", on a device known as a Friden Flexowriter (a cross between a keypunch and a typewriter). This way, the computer could be used for meaningful work at the same time. You would then feed the TECO program in to the computer through its "high-speed" (200 cps) reader, followed by the original tape (with errors). The TECO program would then automatically punch a corrected tape (at a "blistering" speed of 60 cps) or print the work to hand in. No time would be wasted in editing...
...or so it was thought. The human factor is fallible, and because the correction tape was a program, it required debugging just like any other. In practice, people continued to edit "expensively". The problem was approached from a different angle, with time-sharing operating systems (where the computer could be used by two or more people at once)---but because TECO was so much more feature-complete and efficient than Expensive Typewriter, it was here to stay.
Around this time, on the West Coast, a new operating system was being written. It was to be known as UNIX, and it would take the world by storm. The original editor on UNIX, Ed, was written in 1969. Eventually, it was subsumed into Em (the Editor for Mortals), Ex (the Extended editor), and finally Vi (the Visual editor) in 1978. UNIX, and its associated utilities, were written in the C programming language, which is portable; the original lineage of TECO was written in PDP assembly, which isn't.
In some ways, TECO and E*/Vi? could not be more different. TECO sees text files as a "stream of tape" while E*/Vi? see them as a "box of cards". TECO is Turing-complete, but neither E* nor Vi are. Vim, a much enhanced re-implementation of Vi, does have a Turing-complete scripting language, but it's separate from the editing commands; in TECO, the command and scripting languages are one and the same. Operationally, though, Ed and its successors are perhaps the most similar thing there is to TECO in that they are modal.
In a modal editor, keys don't always do the same things; it depends on which mode is active. You constantly switch between modes: there is a mode for navigation, one for insertion, one for selecting regions of text, one for entering commands, etc. This sounds complicated, but you quickly get used to it. The biggest operational difference between Vim/TECO on one hand and editors like Emacs on the other is the modal interface. If you use Vim or TECO, you don't use complicated shortcuts---you speak a language. You reduce the risk of carpal tunnel syndrome by not hitting several keys at once, but by pressing single keys in sequence.
In 1976, Richard M. Stallman, a hippie known for the GNU portion of GNU/Linux?, released the first version of Emacs (the Editor Macros for TECO) in co-ooperation with Guy Steele. Stallman and Steele evidently had a distaste for modal editors like Vi and TECO. Emacs works like a typewriter and the majority of editors in common use today: typing letters and numbers simply inserts them into the buffer. By necessity, commands are entered by pressing multiple keys at a time (typically, one or more of Escape, Meta, Alt, Control, and Shift).
Eventually, Emacs was re-written from the ground up in Lisp, so that it no longer used TECO. It now stands as a utility on its own, somewhere between text editor and operating system. Indeed, editors (including TECO and Vi) have been written in Lisp to run on Emacs, bringing the story full circle. Unfortunately, the original version of TECO is only compatible with OpenVMS and HP/UX machines. That may have been what brought TECO into obscurity: as UNIX/Linux? edged out ITS and VMS as the high-end operating system of choice, Ed, Em, Ex, Vi, and later Emacs did the same to TECO.
There is another possibility. While a full-screen mode was made available for DEC TECO in 1964, it took a while for other operating systems to catch up. The first so-called Video TECO implementation for Mac OS and UNIX was released in 1986, while Vi came out ten years earlier, long enough to be entrenched in hacker culture as the editor of choice. The lack of a video implementation can seriously hamper the adoption of an editor, no matter how featureful it might be, because formerly, the only way to observe the state of the text during the editing process was to type in commands that would cause the text (or portions thereof) to be typed out on the console typewriter.