Kile

La première chose que l’on remarque en ouvrant Kile, c’est que la frappe y a exactement la sensation de l’éditeur de texte Kate. Ce n’est pas une illusion. Kile est l’environnement LaTeX entretenu par le projet KDE, et la surface sur laquelle on écrit est le composant d’édition de Kate, KatePart, intégré tel quel — le manuel le dit mot pour mot. Par la même logique, ce qui affiche le PDF n’est pas Kile lui-même mais un Okular incorporé. Cette page suit cette habitude KDE d’assembler des composants à travers les projets de Kile, son système d’outils et de compilation aux jetons tels que %source, et QuickPreview, qui compose une sélection et n’en montre que cela.

Pourquoi la zone d’édition de Kile se comporte comme Kate

Une phrase du manuel explique tout : « Kile is based on the Kate editor component, i.e. a lot of its editing capabilities stem from the Kate editor component itself. » KDE dispose d’un mécanisme nommé KParts, qui permet d’intégrer entièrement le composant d’une application dans une autre ; Kile s’en sert pour placer le moteur d’édition de Kate au cœur de sa propre fenêtre. Voilà pourquoi la coloration syntaxique, la recherche et le remplacement, les numéros de ligne, la sélection par blocs et le mode de saisie Vi ne viennent pas de Kile mais de Kate. Qui a l’habitude de configurer Kate emporte ses réflexes tels quels. À l’inverse : lorsque quelque chose déplaît dans la zone d’édition, le réglage à modifier est celui de KatePart, pas celui de Kile.

Par-dessus, Kile pose la part qui connaît LaTeX : la complétion automatique des environnements, qui place d’un coup la paire \begin{...}…\end{...} ; des palettes qui insèrent symboles et balises d’un clic ; un assistant QuickStart accompagné de modèles, qui règle \documentclass et le format du papier en un seul dialogue ; et la Structure View à gauche. La vue de structure dispose en un seul arbre les titres, les étiquettes et les fichiers appelés, et Jump to Structure Element conduit à n’importe lequel d’entre eux. La force à manier le texte, héritée de Kate, et la connaissance de LaTeX, ajoutée par Kile : cette structure à deux couches est le plan même de Kile.

Cette architecture est née d’une passation vers 2003. Kile a été fondé par Pascal Brachet — celui-là même qui écrira plus tard Texmaker. Lorsque Jeroen Wijnhout lui a écrit pour proposer des fonctions, Brachet lui a cédé le projet tout entier. Le jalon suivant, sous Wijnhout, fut la version 1.6, dont la rubrique « major » du journal des modifications ne compte que deux lignes : « new editor (katepart) » et « project management ». Les deux piliers qui définissent le caractère de Kile — une zone d’édition héritée de Kate et un projet qui rassemble plusieurs fichiers — sont donc arrivés dans une seule et même version. La maintenance est ensuite passée à une équipe menée par Michel Ludwig. Au passage : kile signifie « coin » ou « chatouiller » en norvégien, et se prononce plutôt /kiːlə/ que comme le prénom anglais Kyle.

Il vaut la peine de dire franchement où en est Kile aujourd’hui. Le développement se poursuit, et le portage vers KDE Frameworks 6 et Qt 6 est déjà accompli — la branche de développement actuelle se construit avec Qt 6, KDE Frameworks 6 et Okular 6. En revanche, les publications sont très espacées : la dernière version stable, 2.1.3, date de 2012, et la série 3.0 en est encore à la bêta, avec une bêta 1 en 2017 et une bêta 4 en mars 2024. Bref, un outil mûr qui fonctionne, et non un éditeur qui change tous les mois. La licence est la GPL v2. Son terrain de prédilection est le bureau KDE sous Linux, mais comme Qt et les bibliothèques KDE sont portées ailleurs, il tourne aussi sous macOS, BSD et Windows — la version Windows est même diffusée par le Microsoft Store.

Projets et document maître : ajouter des chapitres sans perdre pied

Réunir plusieurs fichiers .tex dans un projet, et Kile retient lequel est le document maître. Le maître est le fichier parent qui porte \documentclass ; une fois déclaré, une compilation lancée depuis un fichier de chapitre part malgré tout du maître. Les outils LaTeX fournis portent le réglage checkForRoot=yes, si bien que Kile s’aperçoit qu’on s’apprête à composer un fichier qui n’est pas la racine d’un document. Le bénéfice ne s’arrête pas à la composition : la complétion de \ref et de \cite traverse tous les fichiers du projet, de sorte qu’on rappelle en écrivant le chapitre 7 une étiquette posée au chapitre 2. C’est cette unité qui empêche une thèse ou un livre découpé en chapitres de devenir malcommode du seul fait du découpage.

Outils et QuickBuild : comment se monte une compilation Kile

Une compilation Kile est faite d’une seule sorte de pièce : l’outil. pdflatex, dvipdfmx et la visionneuse PDF sont des outils de même forme, chacun portant une class, le command à exécuter, ses options et les extensions from/to qui disent ce qu’il consomme et produit. Les menus les répartissent par classe dans Build → Compile, Convert et View, et l’on modifie ce qu’est réellement chacun sous Settings → Configure Kile... → Tools+Build. Cette uniformité fait la force de Kile : ajouter une conversion revient simplement à créer un outil de plus.

L’outil PDFLaTeX livré d’origine a pdflatex pour commande et -interaction=nonstopmode %source pour options. -synctex=1 n’y figure pas par défaut : il faut donc l’ajouter soi-même pour utiliser les recherches avant et inverse — cet oubli est la cause habituelle du « j’ai tout réglé et rien ne se synchronise ». Le même outil porte checkForRoot=yes (vérifier qu’on ne compose pas un fichier qui n’est pas la racine), jumpToFirstError=yes (sauter à la première erreur) et autoRun=yes (déterminer seul si des passes auxiliaires comme BibTeX, makeindex ou Asymptote sont nécessaires, et les lancer). Grâce à autoRun, un document simple ne demande aucune réflexion sur le nombre de passes.

-interaction=nonstopmode -synctex=1 %source

Les jetons commençant par % que l’on écrit dans le champ des options sont les espaces réservés de Kile, remplacés par les valeurs réelles juste avant le lancement de l’outil. Les deux plus courants sont %source, qui désigne le fichier traité, et %S, le même nom sans extension ; les outils de conversion et les visionneuses externes réclament en outre des jetons pointant vers la sortie.

Par-dessus vient QuickBuild. Ce n’est pas un programme à part mais une Sequence qui appelle des outils dans l’ordre, et son contenu tient en une ligne nommant ceux-ci, par exemple sequence=PDFLaTeX,ViewPDF. Celle qui est sélectionnée d’origine est PDFLaTeX+ViewPDF : composer avec pdfLaTeX puis afficher le résultat. Les séquences fournies figurent ci-dessous ; celles qui se terminent par ForwardPDF font ouvrir à la visionneuse, à chaque compilation, la page où se trouve le curseur. On peut évidemment les réordonner ou en ajouter.

• PDFLaTeX+ViewPDF — droit au PDF avec pdfLaTeX, puis affichage. Le réglage d’origine.
• LaTeX+DVItoPDF+ViewPDF — par un DVI, converti avec dvipdfmx. La voie habituelle pour le japonais.
• LaTeX+DVItoPS+ViewPS et LaTeX+DVItoPS+PStoPDF+ViewPDF — les voies qui passent par PostScript.
• LuaLaTeX+ViewPDF — droit au PDF avec LuaLaTeX, puis affichage.
• PDFLaTeX+ForwardPDF et LuaLaTeX+ForwardPDF — les mêmes, mais avec ouverture en recherche avant plutôt qu’un simple affichage.

Régler les outils pour le japonais : upLaTeX et dvipdfmx

La voie japonaise établie, upLaTeX + dvipdfmx, prend dans Kile la forme de deux outils réunis en une séquence. D’abord l’outil de la famille LaTeX : mettre uplatex comme commande et les options ci-dessous. Ne pas oublier d’y placer -synctex=1.

-synctex=1 -interaction=nonstopmode %source

Vient ensuite l’outil DVItoPDF, qui transforme le DVI en PDF. D’origine, sa commande est dvipdfmx et ses options %S.dvi ; les déclarations from=dvi et to=pdf indiquent à Kile que cette étape consomme un DVI et produit un PDF. Si l’on écrit %S.dvi, c’est que même lorsque l’original s’appelle chapter1.tex, la pièce à transmettre est chapter1.dvi — retirer l’extension pour en poser une autre, telle est précisément la fonction de %S. Ces deux outils placés dans la séquence LaTeX+DVItoPDF+ViewPDF, un document japonais se construit d’un seul geste. Par souci d’exhaustivité, orienter aussi les outils de bibliographie et d’index vers upbibtex et upmendex, qui connaissent le japonais.

%S.dvi

Pour que le nombre de passes et les dépendances soient pris en charge plus sûrement, l’usage est d’ajouter un outil qui appelle latexmk et de réduire QuickBuild à lui seul. Créer un nouvel outil avec la commande latexmk et les options ci-dessous. Une mise en garde : latexmk possède lui aussi un jeton %S, dont le sens diffère de celui de Kile. Les jetons % écrits dans les réglages d’un outil sont développés par Kile ; ceux écrits dans un .latexmkrc le sont par latexmk. Ce sont deux langages distincts, à ne pas mélanger. La configuration de latexmk fait l’objet d’une autre page.

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

De concert avec Okular : régler les recherches avant et inverse

Par la même logique qui a placé KatePart dans la zone d’édition, ce qui affiche le PDF est un composant de la visionneuse standard de KDE, Okular. Tous les outils d’affichage sont réglés d’origine sur Document Viewer — c’est-à-dire un Okular logé dans la fenêtre même de Kile —, mais des réglages appelant la commande okular dans une fenêtre séparée existent aussi. Que la source et le PDF voisinent dans une seule fenêtre découle de cette incorporation, tout comme la fluidité des allers-retours.

La recherche avant et le simple affichage sont deux outils distincts ; les confondre explique qu’une configuration recopiée reste sans effet. Le ViewPDF d’affichage ne transmet à Okular que %target (ou --unique %target), tandis que le ForwardPDF de recherche avant lui transmet --unique %absolute_target. C’est %absolute_target qui porte la position, dans le PDF de sortie, correspondant à la ligne courante ; voilà pourquoi Okular peut ouvrir au paragraphe sous le curseur. La méprise fréquente consiste à laisser %target dans le champ ViewPDF puis à s’étonner que la recherche avant ne fasse rien ; le correctif se trouve du côté de ForwardPDF, et la séquence QuickBuild doit se terminer par ForwardPDF.

La recherche inverse se règle du côté d’Okular, non dans Kile. Dans les réglages d’Okular, désigner Kile comme éditeur avec la commande de lancement kile --line %l ; un clic avec la touche Maj sur un point du PDF ramène alors à la ligne correspondante dans Kile. La recherche avant va de Kile vers Okular et l’inverse d’Okular vers Kile : retenir que la direction détermine l’emplacement du réglage évite bien des détours. Ce que le mécanisme de synchronisation enregistre réellement — le contenu d’un .synctex.gz — fait l’objet d’une page distincte.

QuickPreview : ne composer que la partie sélectionnée

QuickPreview épargne une reconstruction complète lorsqu’on n’a modifié qu’une formule au milieu d’un long document. Il enveloppe la seule sélection dans un petit document jetable, le traite et en montre le résultat. Quatre façons de délimiter la portion existent : la sélection elle-même, l’unique environnement où se trouve le curseur (le corps d’un \begin{...}…\end{...}), un seul sous-document appelé par \input, et le groupe de formules entourant le curseur. Le résultat peut s’afficher dans une barre au bas de la fenêtre plutôt que dans une fenêtre séparée : en peaufinant l’allure d’un tableau ou d’une longue équation, l’attente d’une compilation entière disparaît. Des outils de prévisualisation dédiés (class=LaTeXpreview) tournent en arrière-plan, ce qui laisse intacts les vrais réglages de compilation.

Ce qu’il faut fixer dès le premier jour avec Kile

La première chose à fixer n’est pas le sens des boutons mais le contenu de QuickBuild. Pour un texte surtout occidental, laisser le réglage PDFLaTeX+ViewPDF ; pour un travail japonais en upLaTeX, choisir LaTeX+DVItoPDF+ViewPDF ; et si les passes de bibliographie et d’index doivent être sûres, n’y mettre qu’un outil latexmk. Cette décision prise tôt, le déroulement — partir d’un fichier de chapitre et toujours compiler le maître — survit à tous les fichiers ajoutés ensuite au projet. Le manuel donne Alt+2 comme raccourci clavier pour compiler la source et note qu’exécuter QuickBuild devrait lancer la visionneuse Okular de lui-même.

Une fois les réglages stabilisés, enregistrer un court main.tex comme projet et vérifier une fois qu’une compilation lancée depuis un fichier de chapitre produit bien le maître. En cas d’erreur, ouvrir le .log par View logfile et avancer avec Next error — jumpToFirstError=yes mène déjà d’office à la première. Parcourir tout ce chemin d’une traite, jusqu’à voir fonctionner la recherche avant d’Okular, et il ne reste plus qu’à ajouter des chapitres.