Los inicios de TECO

Dan Murphy

Se me ocurrió el nombre TECO en 1962 mientras estaba sentado en Ye Hong
Guey, mi restaurante favorito en el barrio chino de Boston durante mis
años de estudiante en el Instituto Tecnológico de Massachusetts. Estaba
trabajando en un pequeño programa para ayudarme a escribir otros
programas, una actividad común en aquella época en la que un ordenador
(el Digital Equipment Corporation PDP-1) se entregaba prácticamente sin
software.

Mi programa había llegado al punto en que necesitaba un nombre, así que
mi amigo Pete Peterson y yo estuvimos barajando posibilidades y sus
acrónimos. Años más tarde, TECO sería conocido por significar Editor y
Corrector de Texto, y así se describe en su documentación. Sin embargo,
el significado original —el que se nos ocurrió aquella noche en la
esquina de las calles Oxford y Beach— era "Editor y Corrector de Cinta".

Uso interactivo del ordenador en el PDP-1

Utilizábamos el término "cinta" porque la cinta de papel perforada era
el único medio para almacenar el código fuente del programa en nuestro
PDP-1. No había disco duro, disquete, cinta magnética ni red. No había
sistema operativo, solo el lector de cinta de papel, la perforadora y
una máquina de escribir de consola. El lector de cinta de papel era
rápido (o al menos así parecía entonces), leyendo 300 caracteres por
segundo. La perforadora era considerablemente más lenta, a 20 caracteres
por segundo. El dispositivo de consola era una máquina de escribir
eléctrica de oficina que se había conectado al PDP-1 para la entrada y
salida de caracteres.

El PDP-1 fue el primer ordenador fabricado y vendido por DEC y, por lo
tanto, la vanguardia de la revolución de los miniordenadores. Sin
embargo, para los estándares actuales, no tenía nada de "mini"; ocupaba
varios armarios altos en su configuración mínima. Todo eso, y tenía una
memoria principal de tan solo 4096 palabras de 18 bits (equivalente a 8
kilobytes). Se trataba de una memoria de núcleos compuesta por diminutos
toroides magnéticos dispuestos en finos hilos formando una malla
tridimensional. Tenía un ciclaje de 5 microsegundos. El procesador
ejecutaba la mayoría de las instrucciones en dos ciclos (10
microsegundos): un ciclo para obtener la instrucción de la memoria y el
segundo para cargar o almacenar el operando.

Algunas instrucciones no hacían referencia a la memoria, por lo que solo
requerían un ciclo.

A pesar de todo, era emocionante poder sentarme frente a la consola y
usar el ordenador de forma interactiva. Mi experiencia previa había sido
con máquinas de tipo mainframe como el IBM 709 o el 7090. Estas
requerían preparar un programa en tarjetas perforadas, enviar el
conjunto al centro de cómputo para su procesamiento por lotes y recibir
al día siguiente una lista impresa con los resultados. Con la PDP-1, el
ciclo programar-compilar-depurar se redujo de horas a minutos. Podía
hacerlo varias veces en la máquina en una sesión de una hora.

En una jugada inteligente para una empresa joven, DEC había donado una
PDP-1 al Laboratorio de Investigación de Electrónica (RLE) del MIT, y
estaba en una sala prácticamente disponible para cualquiera, incluidos
los estudiantes de pregrado, que quisieran experimentar con ella. Pronto
hubo muchos interesados. Como solo una persona podía usar la PDP-1 a la
vez, el tiempo de computadora escaseó rápidamente, y aún era necesario
preparar la mayor cantidad de programas posible fuera de línea. Esto lo
hacíamos con las máquinas de escribir Frieden Flexowriter, dispositivos
similares a las máquinas de escribir, con lector de cinta de papel y
perforadora. Los programas debían escribirse a mano primero, ya que las
Flexowriter carecían de capacidades de edición. Lo máximo que se podía
hacer era anular un carácter previamente perforado retrocediendo la
cinta perforando la misma línea.

La cinta de papel era más práctica que las tarjetas perforadas en
algunos aspectos. Era más ligera que las tarjetas para un número
determinado de líneas de programa, y si se caía accidentalmente, no se
desordenaban todas las líneas de código. Esta era también su mayor
debilidad. Cuando se necesitaba modificar un programa —añadir, cambiar o
eliminar algunas líneas— no se podían simplemente reemplazar esas líneas
como se hacía con las tarjetas; había que perforar una cinta
completamente nueva. Por lo tanto, editar en la Flexowriter era un
proceso laborioso de leer una cinta fuente existente y perforar
simultáneamente una nueva, deteniéndose en cada punto donde se debían
realizar cambios para escribir el nuevo material y omitir el material
antiguo no deseado.

También era posible editar en el ordenador, que es lo que hacíamos
mientras depurábamos y recompilábamos durante nuestros ratos libres de
ordenador. El editor del PDP-1 tenía una interfaz sencilla orientada a
líneas que permitía a los usuarios recorrer una cinta de papel
existente, añadiendo o reemplazando líneas para generar una nueva
versión del fuente. Sin embargo, usar este editor consumía un valioso
tiempo de computadora, y utilizaba toda la capacidad del ordenador para
realizar una tarea comparativamente "sencilla", por lo que se le conocía
como la "Máquina de Escribir Cara".

Que la "Máquina de Escribir Cara" sólo pudiera añadir, borrar o
reemplazar líneas completas de texto me molestaba considerablemente. Era
un inconveniente de las tarjetas perforadas que cualquier cambio en una
línea requiriera volver a escribirla por completo en una nueva tarjeta,
y no entendía por qué esa limitación debía existir en este nuevo medio
donde no había separación física entre una línea y la siguiente, más
allá del caracter de retorno del carro.

El nacimiento de TECO

Así pues, decidí escribir un programa que, como "Expensive Typewriter",
me permitiera copiar una cinta de papel mientras realizaba cambios sobre
la marcha y me permitiera hacer esos cambios carácter por carácter. En
consecuencia, los primeros comandos incluirían este tipo de funciones:

* borrar un carácter,

* borrar una línea (a veces seguía siendo conveniente trabajar con
líneas),

* insertar texto (desde un carácter hasta varias líneas) y

* buscar texto en el punto donde se deseaba realizar cambios.

TECO no se concibió inicialmente como un editor interactivo en línea.
Debido a la escasez de tiempo de máquina, la edición en línea todavía se
consideraba un despilfarro, y realmente no queríamos esperar hasta
nuestro siguiente horario asignado para alistar la siguiente revisión
del código fuente.

Por lo tanto, TECO estaba diseñado para usarse "fuera de línea", en la
Flexowriter, donde preparábamos una cinta de papel aparte con los
comandos necesarios para editar nuestra cinta fuente existente.

Como suele decirse, "en aquel momento parecía una buena idea". En otras
palabras, la idea era marcar manualmente los cambios en el código fuente
e introducir los comandos TECO necesarios para realizar esos cambios en
la Flexowriter (es decir, buscar un punto, borrar, insertar, pasar al
siguiente). Luego, cuando llegaba el momento de usar el ordenador,
cargábamos TECO y leíamos la cinta de comandos, de modo que TECO pudiera
leer nuestra antigua cinta fuente y generar rápidamente una nueva.

Por lo tanto, en sus inicios, TECO era un lenguaje para describir los
cambios en diferido en el código fuente de un programa o, más
generalmente, en un flujo de texto.

Con el tiempo, y a medida que continuaba su evolución, este resultó ser
su verdadero potencial.

TECO se vuelve interactivo

A corto plazo, sin embargo, la preparación de comandos fuera de línea
resultó poco práctica.

Era imposible para la mayoría de los mortales comunes, incluyéndome a
mí, preparar consistentemente cintas de comandos que funcionaran
correctamente de forma diferida. Como cualquier otro programa, tendrían
errores que solo se harían evidentes al usar la computadora. Por lo
tanto, desde el principio añadí un modo a TECO que prescindía de leer
primero la cinta de comandos y simplemente nos permitía introducir
comandos en la máquina de escribir de la consola.

Ni que decir tiene que esta fue una experiencia completamente diferente.
Podíamos introducir uno o unos pocos comandos, asegurarnos de que el
resultado fuera correcto y luego continuar.

Aunque bastante interactivo, TECO no era un editor de pantalla en ese
momento. Si bien nuestro PDP-1 tenía un dispositivo de visualización
CRT, no existía ni el paradigma ni el código para mostrar texto. Por lo
tanto, el código fuente se guardaba en copia dura (impresó en papel), y
editar en línea significaba mirar unas pocas líneas a la vez escritas en
papel.

Con la edición interactiva, pronto se hicieron necesarias varias
mejoras. Rápidamente quedó claro que moverse por una cinta perforada de
origen en una sola dirección seguía siendo engorroso. Un error
especialmente fácil, pero doloroso, era escribir mal un comando de
búsqueda, lo que hacía que el texto buscado no se encontrara y la copia
continuara hasta el final de la cinta. Para solucionar este problema,
decidí que sería conveniente leer un fragmento del origen en memoria
temporal, donde se podrían realizar varias ediciones antes de copiarlo a
la nueva cinta de papel. La unidad natural para esto era una página
mecanografiada. La mayoría del código fuente se encontraba paginado a
este tamaño porque en las Flexowriters y la máquina de escribir de
consola usábamos papel tamaño carta plegado en acordeón.

Esto fue de gran ayuda. La búsqueda habitual se limitaba a la página
actual, por lo que un fallo en la búsqueda no suponía ningún problema.
Simplemente se volvía al principio de la página y se volvía a intentar.
Además, podíamos hacer algunos cambios, ver cómo quedaban y, si aún no
estaban bien, hacer más modificaciones (dentro de la página).

La edición página por página requería nuevos comandos para controlar la
ubicación en la que se realizaría la edición (el punto), para pasar a la
página siguiente o al final de la cinta, y para realizar búsquedas que
no se limitaran a la página actual. Esta búsqueda aún conllevaba el
riesgo de ir demasiado lejos, pero como se usaba con menos frecuencia y
solo para llegar a la página correcta, ese riesgo era mucho menor.

Podrías preguntarte: ¿por qué solo una página a la vez? ¿Por qué no leer
toda la cinta fuente? Como mencioné antes, nuestro PDP-1 tenía una
memoria total de aproximadamente 8 kilobytes, y esta tenía que contener
todo el programa TECO, así como el texto que se estaba editando. No fue
hasta muchos años después que las memorias se hicieron lo
suficientemente grandes como para que cargar el archivo completo se
volviera práctico y rutinario.

Una mejora en ese sentido fue posible cuando se le añadió un tambor de
intercambio RLE al PDP-1. Si bien este dispositivo no era lo
suficientemente grande como para servir como almacenamiento permanente
para programas o código fuente, era rápido y podía usarse para sortear
la limitación de la memoria principal. Para TECO, implementé un
mecanismo de paginación que permitía que el búfer de edición principal
fuera mucho mayor de lo que cabía en la memoria.

Aprovecharía algunas de estas ideas de paginación unos años más tarde en
la implementación de otros sistemas multiusuario, culminando en los
sistemas operativos TENEX y TOPS-20 1.2. La cinta perforada siguió
siendo de uso común al menos hasta finales de la década de 1960 en
varios sistemas, pero TECO admitía otros métodos.

La tecnología de cinta magnética se implementó casi tan pronto como
estuvo disponible en cualquier máquina que usábamos. Uno de los otros
PDP-1 del MIT tenía una unidad de cinta magnética, y rápidamente añadí
un controlador de cinta magnética a TECO. De nuevo, en ese momento no
había sistema operativo, ni siquiera bibliotecas de E/S comunes, así que
cada programa tenía comandos y rutinas de E/S separadas añadidas para
cada dispositivo.

La cinta magnética nunca fue práctica para el almacenamiento de
programas, por supuesto, aunque era asombrosamente rápida en comparación
con la cinta de papel. Mucho mejor era la DECtape (o MicroTape), el
sistema de cinta de carrete pequeño con direccionamiento por bloques que
finalmente se añadió al PDP-1 y estuvo disponible en todos los sistemas
DEC durante muchos años. DECtape tenía un sistema de archivos básico que
admitía un número modesto de archivos con nombre en cada carrete y la
capacidad de reescribir archivos cualquier número de veces. Esto
requirió que TECO no sólo extrayera un flujo de datos de un dispositivo
de entrada serial, sino que desarrollara la capacidad de abrir un
archivo por nombre.

Incluso cuando se popularizaron el tiempo de cómputo compartido y los
sistemas de archivos basados ​​en disco, la edición en TECO seguía
realizándose - en su mayor parte - página a página. El uso eficiente de
la memoria seguía siendo importante y, a pesar de su potencia, TECO era
económico de ejecutar.

Al principio, no le di mucha importancia al diseño de la interfaz de
usuario de TECO.

En realidad, ese concepto no existía en el ámbito de las herramientas de
programación en aquel entonces. El programa interactivo más utilizado
era el depurador DDT, que contaba con un conjunto de comandos de una
sola letra precedidos de argumentos numéricos. Por ejemplo, para
examinar la posición 123 de un programa, se escribía 123/. DDT actuaba
inmediatamente sobre la barra diagonal e imprimía el contenido, por lo
que la línea aparecía como 123/lac foo. TECO seguía este formato, con
comandos como:

* 5d, que significa "borrar cinco caracteres";

* 3c, que significa "avanzar tres caracteres";

* 10l, que significa "avanzar 10 líneas";

* 2k, que significa "eliminar dos líneas"; y

* iTEXTO<term>, que significa "insertar TEXTO, o todo desde la i inicial
hasta el carácter especial de terminación de texto".

Como mencioné antes, basé el diseño inicial de los comandos TECO en su
introducción diferida, pero siguieron funcionando bien cuando el uso de
cómputo interactivo se volvió una norma.

(Véase la barra lateral para una nota interesante sobre la distribución
de comandos basada en caracteres).

A partir de ese comienzo relativamente simple, continué añadiendo
mejoras. Algunas de ellas se centraron en hacer el lenguaje más
consistente y general. Por ejemplo, no necesitábamos un comando aparte
para mover el puntero en reversa (el comando r original); un argumento
negativo para el comando de avance de caracteres bastaba para ello. Lo
mismo se aplicaba a los comandos que operaban sobre líneas: -3l
significaba "retroceder tres líneas", y -5k significaba "borrar las
cinco líneas anteriores". 0 (cero) representaba "la línea actual", por
lo que 0l significaba "ir al principio de la línea actual".

Varias construcciones sencillas se convirtieron rápidamente en un hábito
para cualquier usuario de TECO, como usar 0kk para "borrar toda la línea
actual", independientemente de la posición del puntero.

(TECO usa la convención de que el argumento por defecto es 1 para la
mayoría de los comandos).

TECO se convierte en un lenguaje de programación.

A finales de 1962, TECO tenía aproximadamente el mismo nivel de
capacidades que los editores sencillos tendrían durante los años
siguientes, pero el desarrollo de TECO no se detuvo ahí. Muchas de las
mejoras posteriores se realizaron simplemente porque se me ocurrió algo
que podía hacer fácilmente o alguien sugirió algo, y parecía una buena
idea. Nuestra mentalidad era que las ideas interesantes eran divertidas
de explorar, incluso si no se nos ocurría un uso práctico o una
necesidad de inmediato.

Las adiciones más significativas —las que empezaron a darle a TECO
cierta potencia como lenguaje de programación o motor de texto— incluían
búferes de texto y la estructura de bucle. TECO manejaba bastante bien
las modificaciones simples de programas en ese momento, pero no ofrecía
una forma de realizar reestructuraciones significativas (por ejemplo,
mover una cantidad considerable de texto de un lugar a otro o replicar
un segmento de texto varias veces). Para proporcionar esto, añadí el
concepto de variables de texto; es decir, una variable que almacenaría
una sección arbitraria de texto.

El comando para mover un rango de texto a una variable de texto era `x`.
(Para entonces, me estaba quedando sin letras sin usar). Su prefijo
identificaba un rango de texto en el búfer, de la misma manera que el
comando k, y la letra que seguía a la x era el nombre de la variable del
conjunto a–z, 0–9. g (get, "obtener") se usaba para copiar el contenido
de una variable de texto en el búfer principal en el punto de edición y
podía usarse cuantas veces quisiera para replicar copias del texto. A
pesar de la falta de una asociación mnemotécnica para x, rápidamente se
volvió natural, casi intuitivo. Escribir algo con x se volvió tan fácil
de pronunciar y comprender para los usuarios de TECO como lo habría sido
"almacenar".

Luego, dado que teníamos la capacidad de almacenar cualquier texto en
una variable, implementé un comando para ejecutar una variable de texto
como una cadena de comandos de TECO. Se podía proporcionar un argumento
opcional en forma de una expresión precedente. De este modo, TECO llegó
a tener una forma de macro o función invocable, y esto se derivó del
concepto original de que una cadena de texto concisa representaría
comandos para modificar otro texto.

Por esa misma época, también descubrí que quería poder realizar cambios
repetitivos y sistemáticos en el texto fuente. Esto incluía casos
sencillos como cambiar todas las apariciones de "foo" por "fie" (lo que
más tarde sería compatible con el comando de reemplazo) y acciones más
allá de la simple búsqueda y reemplazo, como "encontrar cada línea que
contenga "foo" y agregar un comentario al final". Esto dio origen a la
estructura de bucle original: (comandos booleano; comandos).

El bucle se ejecutaría cero o más veces hasta que la prueba diera falsa.
Existía una variante de búsqueda que devolvía verdadero solo si se
encontraba el texto, por lo que los bucles de búsqueda y modificación
eran sencillos. Los comandos de inicio y fin de bucle aparecían como
paréntesis con un punto en medio en el PDP-1. Las versiones posteriores
de TECO basadas en ASCII usaban signos mayor y menor para dicho
propósito.

Por esta época también se añadieron variables enteras, de nuevo del
conjunto de letras a–z, 0–9. u ("usar") almacenaba su argumento en la
variable, y q ("cantidad") representaba el valor almacenado en una
expresión.

El mismo nombre de variable podía tener un valor de texto y uno
numérico; el comando determinaba a cuál se hacía referencia. Dado que se
aceptaban expresiones aritméticas simples, un bucle que se ejecutara,
por ejemplo, cinco veces, podía escribirse como 5ua ( qa; comando qa-1ua
)

Los espacios y los saltos de línea no tenían importancia sintáctica.

Como muestra este sencillo cuasi-ejemplo, TECO era, ante todo, conciso.
Se podían escribir bucles bastante complejos y otras secuencias de
comandos en TECO, y en su mayoría parecían ruido de línea. TECO fue uno
de los primeros lenguajes en dar origen a la práctica de entregarle a
alguien una línea de código casi ininteligible y preguntarle con una
sonrisa: "Dime qué hace".

Sin embargo, TECO llegó a figurar en el "listado de lenguajes de
programación conocidos" de Jean Sammet de finales de la década de 1960.

Ha habido innumerables comentarios a lo largo de los años sobre lo poco
conocido que es el lenguaje TECO. Pocos discutirían la premisa de que es
más fácil de escribir que de leer. Como editor - sin embargo - su
tersitud era una de sus ventajas. Los usuarios habituales aprendían
rápidamente las secuencias de comandos más frecuentes y ni siquiera
necesitaban pensar en ellas. Especialmente después de que se
popularizaran los editores WYSIWYG, la afirmación de que los usuarios
comunes solo podían manejar editores extensos y orientados a líneas
desapareció.

Esto fue objeto de un acalorado debate dentro de DEC durante algunos
años, enfrentando a los desarrolladores con los responsables de negocios
y marketing. Hoy, si consideramos todas las oscuras secuencias de teclas
disponibles en el software más comúnmente utilizado, con modificadores
como Control, Alt, Shift y otros, TECO parece casi simple.

TECO se traslada a nuevas máquinas

En pocos meses, TECO se utilizaba en varias PDP-1 del MIT. Además de la
primera en RLE, había una que el profesor Martin Deutsch utilizaba para
el análisis de fotografías de cámaras de burbujas. Durante mi último año
de licenciatura, de Deutsch me contrató para seguir trabajando en TECO y
en otras herramientas de programación que había desarrollado.

También se había instalado una PDP-1 en el nuevo edificio Tech Square,
donde Marvin Minsky tenía su laboratorio de IA. Allí también se
instalaría la primera DEC PDP-6 del MIT en 1965, y se convertiría en la
primera máquina a la que se adaptaría TECO. Yo no realicé esta
adaptación; Fue realizado por Stewart Nelson, Richard Greenblatt y Jack
Holloway, quienes habían estado usando el PDP-1 de IA y fueron de los
primeros en tener acceso al nuevo PDP-6. Algunas mejoras ya se habían
realizado en la versión del PDP-1 por el grupo de IA, y se usaba mucho
allí. Por lo tanto, adaptarlo al nuevo PDP-6 era un proyecto urgente.

Anteriormente, DEC me había ofrecido un trabajo de medio tiempo para
realizar esa adaptación para su nueva máquina, aún en desarrollo, pero
estaba tratando de terminar mi último año de universidad sin reprobar,
así que sabiamente rechacé la oferta.

El TECO del PDP-1 estaba escrito en lenguaje ensamblador, y simplemente
recompilar el código fuente, incluso con algunas modificaciones, era
imposible. No obstante, el PDP-6 contaba con un conjunto de
instrucciones mucho más potente y general, por lo que gran parte del
TECO podía traducirse fácilmente (aunque solo manualmente) instrucción
por instrucción, manteniendo el lenguaje ensamblador. Una gran
diferencia fue el cambio de conjunto de caracteres. El PDP-1 utilizaba
una codificación llamada FIO-DEC (el código de cinta de papel de Frieden
adoptado por DEC). El PDP-6 utilizaba un Teletipo Modelo 35 o 33, que
admitía ASCII (solo mayúsculas).

Otra mejora iniciada en el TECO del PDP-1 y que se hizo fundamental en
el PDP-6 fue el uso de la pantalla para mostrar el texto alrededor del
puntero de edición. Esto aún no era edición en pantalla en el sentido
actual; los comandos se seguían introduciendo y reproduciendo en el
teletipo de la consola, pero la retroalimentación al usuario mejoró
considerablemente. No fue hasta algunos años después que las terminales
basadas en CRT se volvieron corrientes. Hasta entonces, la mayoría de
los usuarios solo podían usar TECO de la forma tradicional en un
dispositivo de impresión.

En los años siguientes se realizaron muchas otras mejoras, impulsadas
por la mayor memoria, potencia y capacidad de programación del PDP-6. El
conjunto de comandos para esa versión aún se puede encontrar con una
búsqueda en la web hoy en día y, hasta donde sé, fue con diferencia la
versión más compleja de TECO que se haya utilizado comúnmente.

Aunque hubo numerosos otros portados para otras máquinas en los años
siguientes, la mayoría eran mucho más básicos y similares a la versión
del PDP-1. Incluso la versión de TECO incluida por DEC en su lanzamiento
inicial del PDP-10 (DecSystem-10) resultó más básica. Bob Clements (en
DEC en ese momento) había tomado como punto de partida una versión
relativamente temprana del TECO del PDP-6 del laboratorio de IAA, la
simplificó para eliminar elementos que no estaban disponibles en la
mayoría de las instalaciones (por ejemplo, la costosa pantalla CRT) o
para los usuarios de terminales de tiempo compartido, y esa se convirtió
en la versión que DEC distribuyó en las instalaciones del PDP-10 y,
posteriormente, del PDP-6. Fue también la versión que llegó a mis manos
cuando Bolt Beranek & Newman (BBN) consiguieron un PDP-10 (1969), a
partir del cual desarrollé hasta aproximadamente 1986.

El espíritu del código abierto

Desde el desarrollo original de TECO hasta la adaptación para PDP-6,
todos estábamos contentos de que DEC o cualquier otra empresa utilizara
o incluso vendiera los programas que habíamos escrito.

Para un estudiante universitario como yo, que la gente los usara y
apreciara era la recompensa. Además, nadie tenía ni idea de cómo o si el
software podía estar protegido por derechos de autor o de alguna otra
manera. Este era el modelo de código abierto en acción mucho antes de
que se popularizara el término.

A partir del PDP-6, TECO se incluyó en el conjunto de software base de
todos los sistemas que ofrecía DEC, incluidos el PDP-8, PDP-11,
DecSystems 10 y 20, y VAX/VMS. También continuó siendo ampliamente
utilizado y mejorado por los hackers del laboratorio de IA de Minsky,
entre los que se encontraba Richard Stallman.

A principios y mediados de la década de 1970, Stallman realizó mejoras
clave en TECO que le permitieron convertirse en un editor en pantalla
totalmente interactivo, al estilo WYSIWYG.

Una pieza clave de esta implementación fue una mejora que permitía que
una sola pulsación de tecla invocara inmediatamente una macro (es decir,
una función a ejecutar). Esto incluía las teclas gráficas normales, de
modo que al escribir una "a" en el modo de entrada de texto normal se
invocaba una función para insertar una "a" en el búfer y, por supuesto,
actualizar la visualización en pantalla. Esto llevó a que muchos
usuarios crearan operaciones de edición activadas por pulsaciones de
teclas, y pronto se hizo un esfuerzo por recopilar aquellas que
resultaban más útiles en un conjunto que pudiera documentarse y ser
utilizado por otros. Esto se convirtió en las macros de editor
originales (Emacs).

TECO continuó siendo el motor de texto de EMACS durante varios años,
pero finalmente fue reemplazado por un lenguaje de manipulación de texto
similar a Lisp conocido como Emacs-Lisp.

También se desarrollaron varias versiones de TECO para terminales de
video, incluida una mía llamada VTECO para TENEX y TOPS-20. Además,
surgieron varios dialectos del lenguaje de comandos TECO, a medida que
diversas ramas de desarrollo y evolución continuaban en diferentes
lugares. El Grupo de Usuarios de DEC (DECUS) contaba con un Grupo de
Interés Especial en TECO (TECO-SIG). Aunque los productos de DEC
siguieron siendo los estamentos donde TECO estuvo disponible más
ampliamente y se usó de la manera más consistente, también se adaptó a
muchos otros productos. El origen de muchas de estas versiones ahora es
difícil o imposible de determinar y trazar.

Reflexiones

Es evidente que TECO ha tenido numerosos usuarios a lo largo de los
años. Unos pocos escribieron o intentaron escribir programas reales en
TECO. Uno de mis primeros ejercicios fue escribir un compilador de
expresiones aritméticas en TECO. Este tomaba una expresión como x ¼ a þ
(b ␄ c)*3/d y la traducía a una secuencia de instrucciones de
ensamblador PDP-1 para realizar el cálculo. Nunca intenté convertirlo en
un compilador práctico; era principalmente una forma de probar la
exhaustividad del conjunto de comandos de TECO y un experimento
interesante.

Otros programas conocidos de TECO incluían una interfaz de correo
electrónico primitiva: un conjunto de macros de TECO de Larry Roberts de
ARPA que permitían leer selectivamente los mensajes de la bandeja de
entrada.

Aunque este nivel de modificación de TECO era inusual, muchos usuarios
creaban sus propias personalizaciones en forma de secuencias de comandos
útiles que podían guardarse como macros de TECO e invocarse rápidamente
en una sesión de edición normal. A diferencia de las capturas de
pulsaciones de teclas en algunos editores actuales, las macros de TECO
eran texto plano, por lo que podían editarse como cualquier otro texto
para depurarlas y mejorarlas. Con esto y la capacidad de usar
estructuras de programación como bucles y búsquedas condicionales en
cualquier momento, TECO ofrecía funcionalidades que muchos antiguos
usuarios de TECO, incluyéndome, echamos de menos en los editores
contemporáneos. Las cosas que solía hacer en TECO sobre la marcha ahora
deben hacerse de forma más laboriosa, o si eso no es tolerable, o
directamente no se hacen en el editor, sino que se utilizan otras
herramientas como Grep, Sed, Awk y Perl.

Para cualquiera que quiera usar TECO ahora, al menos ocasionalmente,
existen versiones disponibles en la web para la mayoría de los sistemas
comunes.