Por qué elegí emacs como mi editor avanzado (2ª parte)
Introducción
Este artículo es la 2ª parte del artículo anterior llamado igual, donde empecé explicando lo que me llevó a terminar usando Emacs como mi editor principal y en general como mi software preferido. Finalmente, después de un pequeño viaje en el tiempo vimos la evolución que tuve desde usar los primeros paquetes ofimáticos, para escribir texto, mis apuntes de la carrera principalmente, hasta que finalmente me decanté por el uso de editores para escribir, programar y vivir en general.
Llegamos a la famosa Guerra Santa de Vim vs Emacs, pero finalmente, dejaré tal guerra a un lado, ya que es un chiste que ya no tiene sentido. No lo tiene por dos motivos. Uno porque ahora la guerra es otra, que sería más bien editores basados en Texto como Emacs, Vim, Nano, etc. vs editores gráficos con Visual Code a la cabeza, aunque hay otras propuestas también muy interesantes.
Como he elegido Emacs y aunque a día de hoy es un híbrido raro entre editor basado en texto y aplicación gráfica, defenderé a los editores en modo texto, ya que son a día de hoy los menos utilizados y, por lo tanto, a los que más cariño les tengo porque además desde mi modesta opinión todo lo basado en texto en general es mejor, sobre todo desde que defiendo a la Permacomputación.
En el principio fue la línea de comandos
Ese es el comienzo de un alegato a favor de las terminales de texto sobre los entornos de trabajo gráficos. La realidad es que la solo estoy de acuerdo con el título del relato, e incluso el creador del mismo también estuvo en contra del mismo, pero eso no es lo importante aquí. De hecho, es muy posible que redacte mi propia versión, haciendo alegoría del título, pero como se suele decir eso es otra historia.
Como expuse en la parte anterior mis comienzos fueron con la línea de comandos, la noto más natural, más práctica y por supuesto más eficiente que los entornos gráficos modernos. Pero al mismo tiempo, entiendo a las personas que nacieron, por decirlo así, con los entornos gráficos, que ven más intuitivos, prácticos y, por lo tanto, piensan que más eficientes. Puedo, desde un punto de vista totalmente de eficiencia, que trabajar con herramientas en modo texto es mucho mejor, más rápido, los procesos se pueden automatizar rápidamente y sin grandes conocimientos en informática y además siempre queda un registro de lo que se hace. Por otro lado, por supuesto la mejor opción es trabajar usando lo mejor de ambos mundos y es algo que ya se hace desde hace mucho. Trabajar en entornos, que podríamos llamar mixtos. Por ejemplo, un ejemplo, totalmente pensando en usuarios sin conocimientos técnicos es cada vez usar más editores de Markdown, que de una manera fácil exporten a PDF o incluso documentos de Word, con la ventaja además de que son editores que buscan también el minimalismo y que tengan pocos elementos visuales buscando lo que ahora se llama programas que no distraigan.
En un futuro, quiero hacer una serie de artículos, que aunque yo no sea un experto en UI/UX, es más bien un recopilatorio de expertos en esto, que reflejan como los programadas modernos, llegan a ser muy malos en este aspecto y son muy sobrecargados llegando a ser muy poco eficientes y molestos para el usuario. Incluso, los productos de Apple, que antes eran buque insignia en este asunto, no lo son ahora y pongo por ejemplo, lo que se está hablando ahora, sobre el nuevo entorno gráfico de Apple. Pero eso será otra historia que se contará en otro momento.
De momento, hablaré de lo que yo defiendo como los grandes editores de todos los tiempos, los dos grandes programas que cogen lo mejor de los entornos mixtos, abrazan el minimalismo estético, pero mantienen una potencia y una funcionalidad increíble.
Vim
Ed
Vim no es el editor más antiguo pero sí uno de ellos. Por un tema de legado, sí podríamos llamarlo el más antiguo porque es una mejora, de una mejora, de posiblemente el mejor editor de todos, pero por supuesto, es un editor para los muy cafeteros.
Hablamos de Ed, que era el editor principal de los sistemas UNIX, creado por Ken Thompson en 1971 para el PDP-11/20 y era un editor de línea enfocado para los teletipos, basado a su vez en el editor en línea QED (Quick Editor) también orientado para línea, desarrollado por Butler Lampson y L. Peter Deutsch para el SDS940, en la Universidad de California en Berkeley.
¿Pero qué son los editores orientados a línea? Aunque a mucha gente le parezca increíble, los ordenadores no tuvieron monitores hasta hace relativamente poco. Antes los grandes sistemas centralizados como los grandes servidores de IBM u otros, que solo estaban en las grandes universidades o grandes empresas, tenían un terminal, que era como una máquina de escribir eléctrica. Así que para comunicarse con los ordenadores se escribían comandos en esa máquina y el computador devolvía a continuación una línea con la contestación. Parece algo retrasado, pero era mucho mejor que las tarjetas perforadas y por supuesto más interactivo.
Aunque luego mejoraron esto con monitores CRT.
Aunque su tasa de refresco era tan lenta que solo eran capaces de mostrar una línea a la vez, por lo que, básicamente la filosofía seguía siendo meter comandos en una línea y el ordenador iba escribiendo una línea a la vez. Puede parecer retrasado, pero era mejor que la lentitud de la máquina de escribir y por supuesto más interactivo.
Vi
La historia de Ed, Ex y Vi y lo que sigue como vemos es la colaboración desinteresada de grandes científicos y mentes de todo el mundo que comparte su conocimiento sin pensar en beneficios económicos, que es la base del Software Libre, y que gracias a él, todos tenemos ordenadores, móviles, etc.
Bien como iba diciendo, inspirado en Ed, George Coulouris, de la Universidad de Londres, creó el editor Em (Ed for Mortals), usando las ventajas de los nuevos terminales con vídeo.
Mientras Coulouris estaba visitando Berkeley, en California, se lo mostró a Bill Joy (cofundador de Sun Microsystem) y este lo modificó para que fuera menos demandante de procesador. Y lo llamó Ex (Extendido)
Más tarde, Bill Joy, le agregó soporte para pantalla completa con un modo nuevo llamado visual mode.
Así, mantenía un modo, línea de comando, al estilo ed o em, como eran los editores orientados a línea, pero también un modo visual más interactivo aprovechando los nuevos terminales gráficos. Para iniciar el editor en uno u otro modo, el modo visual o el modo orientado a línea, se hacía con dos comandos. El comando ex para el modo orientado a línea, y el comando vi para el modo visual.
Por lo que en un principio no podemos hablar de Vi como un programa sino como de un modo de Ex. La historia completa por parte de Coulouris está contada aquí.
Joy también explica en otras entrevistas que en un principio Em no funcionaba muy bien en los terminales ADM-3A. Así que, tanto él como Chuck Haley, un compañero de Joy, que colaboran mucho juntos, modificaron el código para que funcionaran bien en esos terminales. Esto es importante porque explica mucho las teclas que usa Vi y por lo tanto sus clones, ya que están determinadas por la terminal ADM-3A
Además en esta otra entrevista realizada en 1999, explica como las circunstancias del desarrollo refleja mucho los comandos usados en Vi y sus clones, y esto es muy extrapolable a otras tecnologías. La entrevista está aquí, y rescato estos fragmentos:
Obtuvimos este código de un chico llamado George Coulouris de la Universidad de Londres llamado Em - Editor para mortales - ya que solo los inmortales podía usar Ed para hacer cualquier cosa.
Yo tenía una terminal en casa y un modem a 300 baudios, durante tras las noches sin dormir de varios meses escribí vi.
– Aquí, el entrevistador pregunta si es verdad como la gente dice que vi, se escribió en un fin de semana.
No. Me tomó mucho tiempo. Fue bastante duro de hacer porque intentaba hacerlo usable sobre un módem de 300 baudios. Esa es la razón de todos esos divertidos comandos. Apenas funcionaba usar un editor de pantalla a través de un módem. Era apenas lo suficientemente rápido. Se mejoró con un módem a 1200 baudios. Un módem de 1200 baudios ahora es muy lento.
La gente que hacía Emacs sentados en los laboratorios en el MIT tenían esencialmente una conexión de fibra óptica en términos contemporáneos. Ellos trabajaban en un PDP-10, la cual era una gran máquina en comparación con una pantalla infinitamente más rápida.
Así que ellos podían tener comandos divertidos con la pantalla parpadeando y todo eso, y mientras tanto, yo estaba sentado en casa, en una especie de vivienda excedente de la Segunda Guerra Mundial en Berkeley, con un módem y un terminal que apenas podía sacar el cursor de la línea inferior.
Eso fue en un mundo que ya no existe. La gente no sabe que vi fue escrito para un mundo que ya no existe más.
Para el que no lo sepa, mucho de los comandos divertidos de los que habla Bill Joy en Vim, son comandos en modo comando como gg, dd, etc que son precisamente así por lo que él dice de conexiones a internet muy lentas de su época y por trabajar desde su casa con módem de 300 y luego a 1200 baudios.
Clones de Vi
Posteriormente muchos editores fueron creados a partir de Vi o basándose en sus ideas. La mayoría de ellos apostaban en mejorar algunas características de Vi o portarlos a otros sistemas fuera de UNIX. Hay muchos, podríamos estar hasta ayer citándolos, o simplemente editores modernos que tienen alguna forma de emular comandos de Vi, pero citaremos a uno de los que más llamó la atención en su día porque no se limitó a ser un clon sino que realmente aportó muchas mejoras. Hablamos de Elvis.
Otro de los que podemos citar, no tanto por su originalidad sino por otras razones que veremos es Stevie.
Este fue un port de Vi, para los sistemas Atari ST aunque su propio creador Tim Thompson lo portó a Amiga, UNIX y OS/2. Hay que decir que Thompson no se basó en Vi, sino que creó el código desde cero. Esto es importante porque el código de Vi, está basado en el código de Ed, el cual tiene la licencia de AT&T, y es por lo que muchos clones de Vi usan en cambio usar el código fuente de Stevie en vez del código de Vi.
Vim
Bueno y ya llegamos a Vim.
Si leemos la entrevista que le hicieron al Bram Moolenaar, pues el cuenta que era estudiante de la universidad y fue forzado a hacer unas prácticas con Vi, donde además, toda la documentación que les fue facilitada fue una sola hoja de papel. Esto le hizo tener una muy mala experiencia con Vi, aunque luego con el tiempo lo apreció mucho. Como en la universidad tenían Amigas ST, pues tenía a mano una versión de Vi para Amigas ST que era Stevie y a partir de ahí modificando su código, pues creó Vim.1
Vim tiene su propia licencia, ya que no estaba de acuerdo con la licencia GPL aunque es compatible con esta. Por otro lado, anima a que dones, si te gusta su software a la ONG ICCF Holland, que ayuda a los niños con enfermedades en el sur de Uganda.
Vim hoy
A diferencia de otros clones de Vi, Vim es el que más ha crecido con diferencia, ha evolucionado y sigue creciendo de una forma meteórica. Tiene gestión de plugins, sintaxis, y todo lo que cualquier editor moderno, pero además, mantiene los modos de editor visual y de comandos que vienen los modos de ex y vi, al no necesitar el uso del ratón si no queremos sigue siendo el más productivo junto con Emacs.
Podéis acceder a esa gráfica interactiva desde aquí.
Para hacer esta parte de Vim, me ha ayudado mucho este artículo, que os lo recomiendo mucho si os gusta Vim. Por supuesto, también he tirado mucho de Wikipedia, que en la época en la que estamos alguna donación les vendría muy bien.
Huevo de Pascua en Vim
Sin en el modo EX se escribe :help 42 saldrá un huevo de Pascual que solo entenderán aquellos que sean fanes de la Guía del autoestopista galáctico.
Emacs
Tengo que decir que estuve trabajando con Vim casi 15 años y estuve muy feliz con él y por eso le sigo teniendo tanto cariño, pero siempre tuve la espinita clavada de no saber Emacs.
Lo que me tiraba para atrás de él, no era tanto su supuesta dificultad sino que lo que pasa cuando usas durante muchos años una herramienta es que si quieres usar una nueva, mentalmente se pretende que rápidamente puedas tener el mismo nivel con la nueva herramienta, y además que se hagan las cosas de una manera similar.
Afortunadamente, me acordé de cómo pasé de usar el Office97, tal como expliqué en el artículo anterior a aprender usar Latex. Lo que en su día hice se puede resumir en unos puntos:
- Olvidarme totalmente de la herramienta anterior y su forma de trabajar
- Adaptarme totalmente a la nueva filosofía de trabajo de la nueva herramienta
- No querer conseguir, el mismo resultado que con la herramienta inicial, tal vez la solución que da la nueva herramienta es mejor. Con Latex fue así.
- Estar muy abierto a todo lo que pueda aprender nuevo con la nueva herramienta
Así que un verano, que no tenía mucho trabajo, vi un artículo en internet que se llamaba "Aprendamos Emacs y dejémonos barba".
Así que puse en acción los puntos anteriores que apliqué para aprender Latex y fue todo bien. Incluso descubrí que en Emacs hay una forma de trabajar con el de la misma forma que lo haríamos con Vim, pero tal como he dicho, lo vi una mala idea y mejor entrar de lleno en el mundo Emacs y toda su forma de trabajar.
El artículo en cuestión me animó mucho, pero aun así voy a citar las cosas que en un principio me costaron:
- La nomenclatura inicial es rara. Por su historia e idiosincrasia concreta es una nomenclatura difícil de entender hoy en día
- La dificultad de no entender claramente, sobre todo en los tutoriales la diferencia de Emacs gráfico y Emacs en modo texto.
- La nula documentación en español, sobre todo por entonces, pero también la clara falta de una documentación más amena y sencilla aunque fuera en inglés. Eso ha cambiado mucho.
- La obsesión de muchos manuales iniciales de querer que aprendieras un montón de combinaciones de teclas que con el tiempo me he dado cuenta de que es algo que no es necesario.
Para mí, lo más importante de aprender Emacs, ahora llevo casi 15 años usándolo, no solo fue el aprender una herramienta que a día de hoy para mí es vital tanto para mi trabajo como para mi vida personal. Como cuando aprendes un idioma, lo más importante no es tanto que hables ese idioma sino todo lo que aprendes relacionado así como el cambio que se produce en tu cerebro.
Cuando aprendes Emacs, no solo estás aprendiendo una herramienta nueva, con una nueva forma de abordar los problemas, sino que además, lo más probable es que acabes aprendiendo algo del lenguaje que hace tan potente a Emacs que es Emacs Lisp. Todo eso hace que nuestro cerebro mejore su plasticidad neuronal. Esto produce efectos como:
- Aumentar la capacidad de concentración.
- Retarda la demencia en la vejez.
- Mejora la captación y el uso de la información.
Por supuesto, cuando ya estaba más introducido en el tema alguien que me ayudó muchísimo fue la increíble Sacha Chua, que además de unos post sobre Emacs increíbles tiene unas inforgrafías también geniales sobre Emacs, Software libre y otras cosas.
El enlace a esta infografía lo tienes aquí.
Emacs no solo es un perfecto sustituto de Vim, además como he dicho, hay formas de trabajar en él exactamente igual que como se hace en Vim, sino que además Emacs va más allá de ser un simple, editor.
Es un programa, que como bien dice el chiste: "Es un gran SO, con un editor decente". Lo único que no solo es un editor decente, además es un editor excelente, que supera no solo a todos los IDE del mercado, sino que además supera a muchos otros programas que no son concretamente editores. Os resumo.
Emacs es:
- Un editor excelente y el más potente de todos.
- Un programa para la gestión de tareas, proyectos, documentación, organización, etc. excelente.
- El mejor programa para gestionar documentos, generar documentación, crear libros, etc.
- El mejor controlador de versiones.
- El mejor gestor de lo que se llama ahora "Segundo cerebro".
- El mejor entorno y más sencillo de usar entorno de programación.
- El mejor entorno de aprendizaje de programación.
- El mejor emulador de máquina Lisp.
Seguro que me dejo muchas cosas, pero ya lo iré comentando en otros artículos.
En futuros artículos explicaré un poco mejor, cosas de por qué la nomenclatura extraña de Emacs y como aprenderla o cómo no es necesario aprender las combinaciones de teclas. También explicaré mejor cómo fui lidiando con los obstáculos iniciales y cómo luego el aprendizaje fue cada vez mejor y más edificante.
While any text editor can save your files, only Emacs can save your soul
Footnotes:
Si sois profesores de universidad, no se lo pongáis fácil a los alumnos. Ponedles las cosas difíciles a ver si alguno hace algo como Vim
