Bienvenido(a) a Grupo Linuxero del Bajío martes, julio 23 2019 @ 08:45 CEST

Emacs contra el resto del mundo

  • Autor:
  • Lecturas 1,511
Artículos En el software libre existen varias discusiones donde el apasionamiento se vuelve de una índole casi religiosa, donde probablemente la más arraigada, con mayor veterania y sin embargo con mucha vigencia todavía, en especial entre los programadores, es la llamada "vi vs emacs". Tal vez valga la pena traer a colación esta discusión, para por lo menos elevar un poco la temperatura de este frío sitio web.

La idea de escribir estas líneas me surgió al escuchar con descuido una charla que presentó Bram Moolenaar para Google. Moolenaar es el líder del proyecto ViM (vi improved). Obviamente estas líneas no son un eco de esa presentación, la gente inteligente irá a escucharla por sus propios oídos. Yo me limitaré sólo a algunas observaciones personales.
Me decanto de una buena vez: soy usuario, a pesar de todo, de emacs. Y digo "a pesar de todo" porque me ha sacado canas verdes, y no solamente a mi, sino también a mis colegas. Pero más que enojarme y mandar al editor al olvido, siento como una especie de mayor cariño por él ya que cada disgusto implica un mayor conocimiento del mismo. Hablando en estos términos, se antoja especular sobre la idea de la relación que lleva uno con su editor, tal vez sea una de las más complicadas dentro de la vida computacional, ¡hay de todo! amor, odio, indiferencia, entrega, sacrificio, pues como bien lo indica Moolenaar al inicio de su plática, la mayor parte del tiempo que estamos frente a la computadora la pasamos utilizando un editor de textos.

Comencé a utilizar emacs casi tan pronto como me inicié en la programación sobre GNU/Linux, y fue así debido a que me enteré que mis ídolos de aquellos días lo utilizaban para su trabajo diario, además de que es considerado como una obra maestra para muchos computólogos de renombre (después de la GPL, emacs es la creación de Richard Stallman más brillante).

Al igual que vi, emacs nació cuando las computadoras no tenían ambientes gráficos, ni ratones: una simple terminal verde y un teclado era toda la interfaz humano-computadora. Y con sólo eso los usuarios debían realizar grandes proezas como artículos con una tipografía espectacular, además de diagramas y gráficos sublimes; escribir enormes y complejos sistemas de software (bases de datos, cálculos matemáticos, y hasta Internet mismo fue escrito sobre ellas). La herramienta que hizo el puente entre esos sistemas de cómputo con tan baja usabilidad y las sublimes tareas realizadas sobre ellas, fue,
indudablemente, en muchos casos, el editor emacs. Un búfer de trabajo limpio, menús activados por teclas, un sub-búfer de comandos, fue la insipración para muchos editores basados en texto, aunque jamás lograron la extensibilidad y la potencia del mencionado.

Pero ahora la historia es distinta, los fabricantes de software y hardware se deshacen por llevar más facilidad de uso al
consumidor. Las alternativas son muchas y muy variadas, pero emacs persiste, pese a mantener su filosofía oscura y casi mística para los ojos profanos.

No obstante, desde tiempos inmemorables, los programadores han discutido sobre el mejor editor para desarrollar software, y dado a que cada persona es diferente y piensa diferente, se adecua mejor o peor a unos y otros editores, por lo que no se vislumbra una respuesta única a este dilema. Hay apasionamientos en estas discusiones y no me
defenderé diciendo que mi convicción por emacs sea de naturaleza racional

Si como muestra basta con un botón, platicaré un poco de lo que ocurre en la oficina. En el grupo de programación de gstreamer cada quien utiliza su propio editor de preferencia: unos, los fieles a Windows, programan desde el IDE de Visual Studio, hasta Source Insight, pasando por Cool Edit y otros más innombrables; mientras que los Linuxeros de
corazón vamos desde gVim hasta el gEdit. Hace poco se desató la discusión, de manera velada, sobre qué editor de texto se debería utilizar.

Todo comenzó con el desarrollo de libgoo, el cual lo escribí enteramente en emacs, utilizando el submodo de C para el desarrollo en Gnome (CamelCase, indentación de 8, k&r), sin embargo no me percaté de un hecho interesante: para emacs la tecla de tabulador, no inserta un caracter de tabulación, sino que ejecuta un comando; por defecto este comando elige entre colocar un grupo de tabuladores para mantener alineado la indentación del código, o también puede insertar un
conjunto de espacios, si el tabulador no da exacto a la indentación, o finalmente, una mezcla de ambos, todo esto buscando minimizar el número de bytes necesarios. Esto en sí no es nada malo, si todo mundo utilizara emacs con esta configuración, el problema fue que cuando el resto abrió en sus editores de preferencia el código, vieron una
indentación tan caótica que casi llegó al grado del escándalo.

Sin embargo, el comando indent y python arreglaron el problema, al menos en el núcleo de la bibliteca. Los amantes de los proceso pondrán el grito en el cielo: "¿Es que acaso no tienen un estándar de programación?". Sí lo tenemos, pero hasta ahora nadie se ha preocupado por seguirlo, además contamos, como ya mencioné, con indent y python para corregirlo cuando venga la auditoría.

Como les decía, el problema de la indentación originó una serié de reproches y recomendaciones por el mejor editor. Los defensores de Source Insight salieron en avanzada, en particular por que dos de ellos son usuarios de Linux, y utilizan dicho software desde VMWare, ya que con Wine no funciona muy bien. Me mostraron con soberbia sus capacidades de mostrar, en diversas ventanas toda la información relacionada al contexto de la edición: si ponen el cursor en una macro, llamada a función o estructura, el editor les muestra automáticamente donde esta declarada y su contenido, muestra en que otras partes del proyecto está siendo utilizada, autocompletado de métodos y variables e infindades más de información relacionada.

Obviamente me sorprendí y hasta pensé en cambiarme a Source Insight, pero mi espíritu purista reaccionó en contra de usar software privativo cuando hay alternativas, pero no cedí en mis intenciones de buscar algo mejor que emacs. Probé entonces la versión de SVN de Anjuta, que sin llegar a ser un SI, tiene características que lo realzan bastante. KDevelop está fuera de consideración debido que me resisto a instalar Qt.

Lo que jamás me convenció es tener un montón de información volando a mi alrededor. Prefiero tener una interfaz limpia, una ventana con únicamente el código que estoy editando, y no perderme información que no requiero en ese momento. Si la requiero, la busco, utilizando cscope, ctags, google, find&grep, etcétera., asimilo la información que requiero y vuelvo al editor; tal vez divida el búfer en dos para ver simultáneamente otro archivo u otra parte del código, o hasta tal
vez en tres.

De acuerdo a la psicología cognitiva, el ser humano sólo puede manejar 7+-2 fuentes de información simultáneas, sin embargo atenderlas implica mayor entropía mental. Prefiero mantener mínimas mi fuentes de información simultáneas y tratar de enforcarme en el problema a resolver en ese momento.

Por otro lado, pensé en todo el tiempo que le he dedicado en aprender a sentirme cómodo en emacs y decidí que sólo por una tabulación mal comprendida no cambiaría de editor, así que mejor configuré mi emacs para que siempre utilizara espacios para la indentación y asunto arreglado.

Para finalizar este conjunto de ideas sin ninguna finalidad, recomiendo que la gente que comienza a programar, no le tema a ViM o a emacs, que los editores asombrosos no siempre son la única a alternativa a evaluar y que cuando escojan su editor, sepan que es una elección a largo plazo, ya que utilizar un editor eficientemente es una tarea que lleva tiempo y sacrificios.