Grupo Linuxero del Bajío

Emacs contra el resto del mundo

Víctor Manuel Jáquez Leal

En el software libre existen varias discusiones donde el apasionamiento sevuelve de una índole casi religiosa, donde probablemente la más arraigada, conmayor veterania y sin embargo con mucha vigencia todavía, en especial entre losprogramadores, es la llamada “vi vs emacs”. Tal vez valga la pena traer acolación esta discusión, para por lo menos elevar un poco la temperatura de estefrío sitio web.

La idea de escribir estas líneas me surgió al escuchar con descuido unacharlaque presentó Bram Moolenaar para Google. Moolenaar es el líder del proyectoViM (vi improved). Obviamente estas líneas no son un eco de esa presentación, lagente inteligente irá a escucharla por sus propios oídos. Yo me limitaré sólo aalgunas observaciones personales.

Me decanto de una buena vez: soy usuario, a pesar de todo, de emacs. Y digo “apesar de todo” porque me ha sacado canas verdes, y no solamente a mi, sinotambié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 unmayor conocimiento del mismo. Hablando en estos términos, se antoja especularsobre la idea de la relación que lleva uno con su editor, tal vez sea una de lasmás complicadas dentro de la vida computacional, ¡hay de todo! amor, odio,indiferencia, entrega, sacrificio, pues como bien lo indica Moolenaar al iniciode su plática, la mayor parte del tiempo que estamos frente a la computadora lapasamos utilizando un editor de textos.

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

Al igual que vi, emacs nació cuando las computadoras no tenían ambientesgráficos, ni ratones: una simple terminal verde y un teclado era toda lainterfaz humano-computadora. Y con sólo eso los usuarios debían realizar grandesproezas como artículos con una tipografía espectacular, además de diagramas ygráficos sublimes; escribir enormes y complejos sistemas de software (bases dedatos, cálculos matemáticos, y hasta Internet mismo fue escrito sobre ellas). Laherramienta que hizo el puente entre esos sistemas de cómputo con tan bajausabilidad 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 paramuchos editores basados en texto, aunque jamás lograron la extensibilidad y lapotencia del mencionado.

Pero ahora la historia es distinta, los fabricantes de software y hardware sedeshacen 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 sobreel mejor editor para desarrollar software, y dado a que cada persona esdiferente 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. Hayapasionamientos 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 laoficina. En el grupo de programación de gstreamer cada quien utiliza su propioeditor de preferencia: unos, los fieles a Windows, programan desde el IDE deVisual Studio, hasta Source Insight, pasando por Cool Edit y otros másinnombrables; mientras que los Linuxeros de corazón vamos desde gVim hasta el gEdit. Hace poco se desató la discusión, demanera velada, sobre qué editor de texto se debería utilizar.

Todo comenzó con el desarrollo de libgoo, el cual lo escribí enteramente enemacs, 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 queejecuta un comando; por defecto este comando elige entre colocar un grupo detabuladores para mantener alineado la indentación del código, o también puedeinsertar un conjunto de espacios, si el tabulador no da exacto a la indentación, ofinalmente, una mezcla de ambos, todo esto buscando minimizar el número de bytesnecesarios. Esto en sí no es nada malo, si todo mundo utilizara emacs con estaconfiguración, el problema fue que cuando el resto abrió en sus editores depreferencia 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 elnú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, perohasta ahora nadie se ha preocupado por seguirlo, además contamos, como yamencioné, 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 yrecomendaciones por el mejor editor. Los defensores de Source Insight salieronen avanzada, en particular por que dos de ellos son usuarios de Linux, yutilizan dicho software desde VMWare, ya que con Wine no funciona muy bien. Memostraron con soberbia sus capacidades de mostrar, en diversas ventanas toda lainformación relacionada al contexto de la edición: si ponen el cursor en unamacro, llamada a función o estructura, el editor les muestra automáticamentedonde esta declarada y su contenido, muestra en que otras partes del proyectoestá siendo utilizada, autocompletado de métodos y variables e infindades más deinformación relacionada.

Obviamente me sorprendí y hasta pensé en cambiarme a Source Insight, pero miespíritu purista reaccionó en contra de usar software privativo cuando hayalternativas, 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, tienecaracterísticas que lo realzan bastante. KDevelop está fuera de consideracióndebido que me resisto a instalar Qt.

Lo que jamás me convenció es tener un montón de información volando a mialrededor. Prefiero tener una interfaz limpia, una ventana con únicamente elcódigo que estoy editando, y no perderme información que no requiero en esemomento. Si la requiero, la busco, utilizando cscope, ctags, google,find&grep, etcétera., asimilo la información que requiero y vuelvo aleditor; tal vez divida el búfer en dos para ver simultáneamente otro archivo uotra 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+-2fuentes de información simultáneas, sin embargo atenderlas implica mayorentropía mental. Prefiero mantener mínimas mi fuentes de información simultáneasy 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 sentirmecómodo en emacs y decidí que sólo por una tabulación mal comprendida nocambiaría de editor, así que mejor configuré mi emacs para que siempre utilizaraespacios para la indentación y asunto arreglado.

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