PDF de programación - Edición Estructurada en Emacs

Edición Estructurada en Emacs

Alejandro Imass

Una guía de novato a novato sobre
DocBook y otros estándares
SGML/XML haciendo hincapié en el uso
de la edición directa y estructurada
utilizando Emacs.

1. Introducción

Este artículo se centra en el uso de Emacs para editar archivos SGML y sus derivados, como por ejemplo
XML y HTML. Si nunca ha usado Emacs o este programa le desagrada por alguna razón, no se
preocupe, a mí también me desagradaba. Siempre me pregunté qué era lo que la gente veía en una cosa
tan complicada y poco amigable como Emacs. Sin embargo, cuando empecé a escribir en Docbook
comprendí inmediatamente la necesidad de una herramienta más sofisticada que un simple editor de
textos a color. En un principio yo hacía mis trabajos utilizando Nedit, uno de mis editores de texto
favoritos, pero no llegó a las expectativas de lo que debía ser, para mí, el perfecto editor de texto
estructurado: con sangrado automático, que dejara bonitos los párrafos, que pudiera chequear la
ortografía solamente de los datos y, lo más importante, que tuviera medios para la validación contextual
en tiempo de ejecución de cualquier DTD. Ahora bien, ésta quizá parezca una lista de deseos muy larga
y difícil de satisfacer, pero descubrí que Emacs puede hacer fácilmente todo esto y mucho, pero mucho
más. Nunca advertí el poder y la flexibilidad de Emacs ya que nunca me impresionó como entorno, lo
advertí en la edición de documentos SGML. De hecho, luego de descubrir Emacs gracias a la edición
estructurada, este programa se ha convertido en mi navaja suiza y espero que, cuando usted termine de
leer este artículo, también se convierta en la suya.

Recientemente he probado LyX con Docbook y ahora puedo concluir que este intento también tiene
futuro y facilita la transición de editores WYSIWYG 1a la manera estructurada de editar textos. Sin
embargo, esta clase de cosas nunca nos darán la libertad, el poder y la flexibilidad que nos pueden dar
herramientas como Emacs + PSGML, especialmente si nos encontramos en un ambiente de
programación y estamos habituados a encarar los proyectos desde ese punto de vista.

Sobre el alcance de este artículo sólo diré que no se trata de una guía para SGML, Docbook o Emacs.
Como ya diré más adelante, el principal objetivo es introducir y discutir el modo principal2 PSGML de
Emacs y las dificultades más importantes con las que se encontraría cualquier usuario al editar
documentos SGML y XML. Este artículo trata de ser una guía para principiantes por lo que la
información que se proveerá aquí debería ser suficiente para poder entender todo sin necesidad de
conocimientos previos. De todos modos espero poder estimular al lector lo suficiente como para
investigar aún más en el tema. Es por esto que se dan algunas referencias y enlaces a otros artículos y
libros al final de este artículo.

1

Edición Estructurada en Emacs

Recordemos también que Docbook, SGML y XML se están moviendo a un ritmo muy rápido y que ya
han surgido varias tendencias. Recomiendo la lectura del excelente artículo de Eric Raymond sobre
Docbook en el cual se explica en qué etapa se encuentra Docbook actualmente y hacia dónde apuntan
varias de las tendencias (hay un enlace al final). También deseo aclarar que este documento discute sobre
el uso de SGML Docbook y no de XML Docbook, formato que parece ser una nueva tendencia. De todos
modos, cualquier cosa que aparezca en este artículo probablemente se aplique también para XML
Docbook que en esencia es la misma cosa. Por lo que entiendo, el modo principal PSGML es capaz de
analizar sintácticamente DTD de tipos SGML y XML (o esquemas3 que es el nombre que se le da en el
mundo XML), lo que es otro motivo para pensar que todo lo que sea mostrado en este artículo se aplicará
a ambas variantes de Docbook.

2. La Fantasía de los Procesadores de Texto

Yo nací en la era de los “Procesadores de textos” por lo que no tuve oportunidad de conocer lo que era
componer tipográficamente hasta que descubrí UNIX y Troff hace cinco años. Aunque suene poco
creíble, quedé encantado con la nueva forma de escribir usando marcas4 y sin tener que preocuparme por
el aspecto de mis documentos pero sí por el contenido y la estructura, lo cual debería ser el principal
objetivo de todos los autores. Más adelante descubrí Ispell y el resto de la filosofía Unix al integrar
muchas y pequeñas piezas que realmente, todas juntas, funcionan perfectamente.

Quizá, como programador, esto sea natural para mi. Me agradó el hecho de poder escribir (y mantener!)
mis documentos de la misma manera en que escribo mis programas. De todos modos no quiero aburrir al
lector con mis experiencias frente a una computadora por lo que, para hacer corta esta historia, un día
descubrí una vieja tradición en computación llamada SGML5, y no pude creer que las computadoras se
volvieran WYSIWYG en vez de volverse WYSIWYM (un concepto extraído de la página de LyX).

He sufrido mucho y en primera persona el calvario de usar Microsoft Word™ para trabajar con
documentos y manuales, en realidad no muy largos. A continuación listo algunas de mis experiencias:

• Los formatos de documentos son difíciles de integrar. Integrar el trabajo de varias personas casi

siempre se convierte en una pesadilla de reformateo, terminando siempre con una docena de estilos
diferentes que son difíciles de limpiar. Dar formato nuevo a un documento Ms-Word es una larga,
manual y tediosa tarea.

• El número de estilos crece fuera de control y no hay manera de poner en vigor un formato. Un usuario

principiante terminará con una docena de formatos distintos o simplemente los ignorará a todos. Por
ejemplo, un novato en Ms-Word (o cualquier otro programa WYSIWYG) probablemente lo que hará
es simplemente cambiar la fuente y el tamaño a mano, en lugar de usar los encabezados y estilos
apropiados.

• En el caso de que las compañías deseen crear plantillas de documentos estándar, las mismas se

impondrán muy poco y probablemente sean todas violadas o mal usadas. Es muy difícil organizar un
estándar para la documentación a nivel de una corporación y probablemente las compañías terminen
con una docena de diferentes “estándares” en todos los departamentos. Por ejemplo, los logotipos y
otros tipos de gráficos de una corporación tienden a mutar con el tiempo en muchos tipos de formas,

2

Edición Estructurada en Emacs

proporciones y tamaños. Al final, cada usuario termina con lo que él cree que es el estándar de la
compañía y, antes de que alguien se de cuenta, nadie sabrá cuál es realmente el logo oficial.

• Al trabajar con documentos de cierto tamaño, el programa tiende a volverse muy inestable,
especialmente si trabajamos con imágenes u otros objetos. Un error típico de Ms-Word es la
misteriosa X que por alguna razón que nadie conoce reemplaza todos nuestros gráficos. Ante este
error el documento es irrecuperable y se deberá reemplazar cada gráfico a mano.

• El formato de un documento Ms-Word es binario, por lo que es básicamente inútil tratar de extraer la
información dentro de ellos. Si las universidades solicitaran trabajos como tesis en estos formatos (y
créanme que las universidades de aquí piden formato Ms-Word), estos serán tan útiles como papeles y
desfavorecerán la creación de bases de datos de información. Por otro lado, si las universidades fueran
inteligentes, pedirían los trabajos en formato SGML para así, más adelante poder crear bases de datos
de conocimiento para que otros estudiantes puedan consultarlas eficientemente.

• El formato binario .doc parece expandirse en tamaño fuera de control cuanto más lo usemos. Solía
haber una opción para compactar estos documentos pero, al parecer, ha desaparecido en las nuevas
versiones de MS-Word. Esto es un real desperdicio de los recursos de una compañía dado que un
usuario común desconoce esta característica: la única manera de resolver este problema es crear un
nuevo documento doc y copiar y pegar todo el contenido del viejo documento en el nuevo.

• Los servidores de las corporaciones que usan estos formatos se alborotan y desorganizan fácilmente.

Encontrar algo que usar se vuelve parecido a buscar piezas esparcidas en un campo de chatarra: se
gastan horas abriendo documentos aquí y allá hasta que por fin se encuentra algo de valor.

• La reutilización de documentos es algo difícil de llevar a cabo y mantener. Por ejemplo, las

presentaciones estándar de una compañía o capítulos estándar son algo muy difícil de integrar en un
documento ya empezado, por lo que estas plantillas tienden a ser copiadas y modificadas por toda la
compañía.

• Si el archivo binario se corrompe (lo cual sucede muy frecuentemente), no hay manera de salvar

nuestra información, la cual está embebida en un formato propietario6

• La información podrá ser exportada en varios tipos de formato, pero siempre utilizando herramientas
propietarias para tal tarea. No se recomienda exportar a otros tipos de formato dado que, además de la
pérdida de datos que esto supone, no será una tarea trivial. Si trabajamos con MS Word y distribuimos
nuestros archivos, estamos obligando a estas personas a utilizar software propietario tanto para leer
como para convertir nuestros documentos a otros formatos.

De cualquier forma, podría seguir escribiendo páginas de todos los problemas que herramientas del tipo
Lo Que Ves Es Lo Que Obtienes (WYSIWYG) han causado a compañías y a la gente durante años.
Personalmente, tuve la experiencia de tener una secretaria que se tomaba una hora o más para escribir
una simple carta (mientras buscaba el logo correcto, chequeaba virus, imprimía y tenía problemas con la
red, etc), una tarea que hace diez años se realizaba en tres minutos en una máquina de escribir común que
no usaba electricidad. He visto estudiantes que derrochan varios días en tratar de integrar las diferentes
partes de un trabajo y a veces pierden meses de tiempo debido a la corrupción de sus documentos o por
virus en los mismos. En cuanto a mí, he perdido días y semanas de tra