Kile

Lo primero que se nota al abrir Kile es que escribir en él se siente exactamente igual que escribir en el editor de texto Kate. No es una ilusión. Kile es el entorno LaTeX que mantiene el proyecto KDE, y la superficie sobre la que se escribe es el componente de edición de Kate, KatePart, incrustado entero: el manual lo dice con esas palabras. Por la misma lógica, lo que muestra el PDF no es Kile sino un Okular incorporado. Esta página sigue esa costumbre de KDE de ensamblar componentes a través de los proyectos de Kile, su sistema de herramientas y compilación con tokens como %source, y QuickPreview, que compone una selección y muestra solo eso.

Por qué la zona de edición de Kile se comporta como Kate

Una frase del manual lo explica todo: «Kile is based on the Kate editor component, i.e. a lot of its editing capabilities stem from the Kate editor component itself.» KDE dispone de un mecanismo llamado KParts que permite incrustar entero el componente de una aplicación dentro de otra, y Kile lo usa para colocar el motor de edición de Kate en el centro de su propia ventana. Por eso el resaltado de sintaxis, la búsqueda y sustitución, los números de línea, la selección por bloques y el modo de entrada Vi no los escribió Kile: los hereda de Kate. Quien esté acostumbrado a configurar Kate se lleva sus hábitos tal cual. Y al revés: cuando algo de la zona de edición molesta, el ajuste que hay que tocar es el de KatePart, no el de Kile.

Encima, Kile pone la parte que conoce LaTeX: el autocompletado de entornos, que coloca de una vez el par \begin{...}…\end{...}; paletas que insertan símbolos y etiquetas con un clic; un asistente QuickStart con sus plantillas, que resuelve \documentclass y el tamaño de papel en un solo diálogo; y la Structure View de la izquierda. La vista de estructura dispone en un único árbol los títulos, las etiquetas y los archivos que se traen, y Jump to Structure Element lleva a cualquiera de ellos. La destreza con el texto, heredada de Kate, y el conocimiento de LaTeX, añadido por Kile: esa estructura de dos capas es el propio diseño de Kile.

Esa arquitectura nació de un relevo hacia 2003. Kile lo fundó Pascal Brachet, el mismo que más tarde escribiría Texmaker. Cuando Jeroen Wijnhout le escribió con ganas de aportar funciones, Brachet le cedió el proyecto entero. El siguiente hito bajo Wijnhout fue la versión 1.6, y el apartado «major» de su registro de cambios tiene solo dos líneas: «new editor (katepart)» y «project management». Es decir: los dos pilares que definen el carácter de Kile —una zona de edición heredada de Kate y un proyecto que reúne varios archivos— llegaron en una misma versión. El mantenimiento pasó después a un equipo encabezado por Michel Ludwig. De paso: kile significa «cuña» o «hacer cosquillas» en noruego, y se pronuncia más cerca de /kiːlə/ que del nombre inglés Kyle.

Conviene decir con franqueza dónde está Kile hoy. El desarrollo continúa y el traslado a KDE Frameworks 6 y Qt 6 ya está hecho: la rama de desarrollo actual se compila contra Qt 6, KDE Frameworks 6 y Okular 6. Al mismo tiempo, las publicaciones están muy espaciadas: la última versión estable, 2.1.3, es de 2012, y la serie 3.0 sigue en beta, con la beta 1 en 2017 y la beta 4 en marzo de 2024. En resumen: una herramienta asentada que funciona, no un editor que cambie cada mes. La licencia es GPL v2. Su terreno propio es el escritorio KDE en Linux, pero como Qt y las bibliotecas de KDE están portadas, también funciona en macOS, BSD y Windows; la compilación para Windows se distribuye incluso por la Microsoft Store.

Proyectos y documento maestro: añadir capítulos sin perder pie

Agrupe varios archivos .tex en un proyecto y Kile recordará cuál de ellos es el documento maestro. El maestro es el archivo padre que lleva \documentclass; una vez declarado, una compilación lanzada desde un archivo hijo sigue arrancando en el maestro. Las herramientas LaTeX de serie llevan el ajuste checkForRoot=yes, de modo que Kile advierte cuándo se va a componer un archivo que no es la raíz de ningún documento. La ventaja no se agota en la composición: el autocompletado de \ref y \cite recorre todos los archivos del proyecto, así que se puede invocar mientras se escribe el capítulo 7 una etiqueta puesta en el capítulo 2. Es esta unidad la que evita que una tesis o un libro repartido en capítulos se vuelva incómodo justamente por haberlo repartido.

Herramientas y QuickBuild: cómo se arma una compilación en Kile

Una compilación de Kile está hecha de una sola clase de pieza: la herramienta. pdflatex, dvipdfmx y el visor de PDF son herramientas de la misma forma, cada una con su class, el command que ejecuta, sus options y las extensiones from/to que dicen qué consume y qué produce. Los menús las reparten por clase en Build → Compile, Convert y View, y lo que cada una es realmente se edita en Settings → Configure Kile... → Tools+Build. Esa uniformidad es la fuerza de Kile: añadir una conversión no es más que crear una herramienta más.

La herramienta PDFLaTeX tal como se entrega tiene pdflatex como orden y -interaction=nonstopmode %source como opciones. -synctex=1 no está por defecto, así que hay que añadirlo a mano si se piensa usar la búsqueda directa e inversa; esa omisión es la causa habitual del «lo configuré y no se sincroniza nada». La misma herramienta lleva checkForRoot=yes (comprobar que no se está componiendo un archivo que no es la raíz), jumpToFirstError=yes (saltar al primer error) y autoRun=yes (decidir por sí misma si hacen falta pasadas auxiliares como BibTeX, makeindex o Asymptote, y ejecutarlas). Gracias a autoRun, un documento sencillo no obliga a pensar en repeticiones.

-interaction=nonstopmode -synctex=1 %source

Los tokens que empiezan por % y se escriben en el campo de opciones son los marcadores de Kile, sustituidos por valores reales justo antes de arrancar la herramienta. Los dos más socorridos son %source, que designa el archivo en proceso, y %S, ese mismo nombre sin extensión; las herramientas de conversión y los visores externos necesitan además tokens que apunten al lado de la salida.

Encima de todo eso está QuickBuild. No es un programa aparte sino una Sequence que llama a las herramientas en orden, y su contenido cabe en una línea que las nombra, como sequence=PDFLaTeX,ViewPDF. La seleccionada de fábrica es PDFLaTeX+ViewPDF: componer con pdfLaTeX y mostrar el resultado. Las secuencias que vienen de serie son las siguientes; las que acaban en ForwardPDF hacen que el visor abra en cada compilación la página donde está el cursor. Por supuesto, cabe reordenarlas o añadir otras propias.

• PDFLaTeX+ViewPDF: directo al PDF con pdfLaTeX y mostrarlo. El ajuste de fábrica.
• LaTeX+DVItoPDF+ViewPDF: pasando por un DVI, convertido con dvipdfmx. La vía habitual para el japonés.
• LaTeX+DVItoPS+ViewPS y LaTeX+DVItoPS+PStoPDF+ViewPDF: las vías que pasan por PostScript.
• LuaLaTeX+ViewPDF: directo al PDF con LuaLaTeX y mostrarlo.
• PDFLaTeX+ForwardPDF y LuaLaTeX+ForwardPDF: lo mismo, pero abriendo con búsqueda directa en vez de una simple visualización.

Configurar herramientas para japonés: upLaTeX y dvipdfmx

La vía japonesa asentada, upLaTeX + dvipdfmx, toma en Kile la forma de dos herramientas unidas en una secuencia. Primero la herramienta de la familia LaTeX: ponga uplatex como orden y las opciones de abajo. No olvide incluir aquí -synctex=1.

-synctex=1 -interaction=nonstopmode %source

Viene después la herramienta DVItoPDF, que convierte el DVI en PDF. De fábrica su orden es dvipdfmx y sus opciones %S.dvi; las declaraciones from=dvi y to=pdf son las que le dicen a Kile que este paso consume un DVI y produce un PDF. Se escribe %S.dvi porque, aunque el original se llame chapter1.tex, lo que hay que entregar es chapter1.dvi: quitar la extensión y poner otra es justamente para lo que sirve %S. Con esas dos herramientas metidas en la secuencia LaTeX+DVItoPDF+ViewPDF, un documento japonés se compila de un golpe. Para que no falte nada, apunte también las herramientas de bibliografía e índice a upbibtex y upmendex, que entienden japonés.

%S.dvi

Si quiere que el número de pasadas y las dependencias se atiendan con más garantías, lo habitual es añadir una herramienta que llame a latexmk y dejar que QuickBuild no contenga nada más. Cree una herramienta nueva con la orden latexmk y las opciones de abajo. Una advertencia: latexmk también tiene un token %S, y no significa lo mismo que el de Kile. Los tokens % escritos en los ajustes de una herramienta los expande Kile; los escritos dentro de un .latexmkrc los expande latexmk. Trátelos como dos lenguajes distintos y no los mezcle. La configuración de latexmk es tema de otra página.

-pdf -synctex=1 -interaction=nonstopmode %source

Junto con Okular: configurar la búsqueda directa e inversa

Por la misma lógica que puso KatePart en la zona de edición, lo que muestra el PDF es un componente del visor estándar de KDE, Okular. Todas las herramientas de visualización vienen ajustadas de fábrica a Document Viewer, es decir, un Okular alojado dentro de la propia ventana de Kile, aunque también hay ajustes que llaman a la orden okular en una ventana aparte. Que el código y el PDF convivan en una sola ventana es consecuencia de esa incorporación, igual que lo fluido del ir y venir.

La búsqueda directa y la simple visualización son dos herramientas distintas, y confundirlas explica que una configuración copiada no funcione. El ViewPDF de solo mostrar entrega a Okular únicamente %target (o --unique %target), mientras que el ForwardPDF de búsqueda directa le entrega --unique %absolute_target. Es %absolute_target el que lleva la posición del PDF de salida correspondiente a la línea actual, y por eso Okular puede abrir en el párrafo bajo el cursor. El desajuste habitual consiste en dejar %target en el campo ViewPDF y luego extrañarse de que la búsqueda directa no haga nada; lo que hay que arreglar está del lado de ForwardPDF, y la secuencia de QuickBuild debe terminar en ForwardPDF.

La búsqueda inversa se configura del lado de Okular, no en Kile. En los ajustes de Okular, indique Kile como editor con la orden de arranque kile --line %l; después, un clic con Mayús sobre un punto del PDF devuelve a la línea correspondiente en Kile. La búsqueda directa va de Kile a Okular y la inversa de Okular a Kile: recordar que la dirección determina dónde vive el ajuste ahorra muchos rodeos. Lo que el mecanismo de sincronización guarda en realidad —qué hay dentro de un .synctex.gz— es asunto de otra página.

QuickPreview: componer solo la parte seleccionada

QuickPreview ahorra una reconstrucción completa cuando lo único que ha cambiado es una fórmula dentro de un documento largo. Envuelve solo la selección en un pequeño documento desechable, lo procesa y muestra el resultado. Hay cuatro maneras de delimitar la porción: la selección misma, el único entorno en el que está el cursor (el cuerpo de un \begin{...}…\end{...}), un solo subdocumento traído con \input, y el grupo de fórmulas que rodea al cursor. El resultado puede aparecer en una barra en la parte inferior de la ventana en lugar de en otra ventana, de modo que al pulir el aspecto de una tabla o de una ecuación larga desaparece la espera de una compilación entera. Detrás corren herramientas de vista previa propias (class=LaTeXpreview), lo que deja intactos los ajustes reales de compilación.

Qué conviene fijar el primer día con Kile

Lo primero que hay que fijar no es qué significan los botones sino qué va dentro de QuickBuild. Para texto sobre todo occidental, deje el ajuste PDFLaTeX+ViewPDF; para trabajo japonés en upLaTeX, elija LaTeX+DVItoPDF+ViewPDF; y si las pasadas de bibliografía e índice deben ser fiables, ponga ahí una única herramienta latexmk. Con eso resuelto pronto, el flujo —arrancar desde un archivo de capítulo y compilar siempre el maestro— sobrevive a todos los archivos que se añadan luego al proyecto. El manual da Alt+2 como atajo de teclado para compilar el código, y señala que ejecutar QuickBuild debería lanzar el visor Okular por sí solo.

Cuando los ajustes se hayan asentado, registre un main.tex breve como proyecto y compruebe una vez que compilar desde un archivo hijo sigue produciendo el maestro. Si aparece un error, abra el .log con View logfile y avance con Next error; al primero ya le lleva jumpToFirstError=yes. Si logra recorrer todo ese camino de una vez, hasta ver funcionar la búsqueda directa de Okular, lo único que queda es ir añadiendo capítulos.