Kile

Das Erste, was beim Öffnen von Kile auffällt, ist, dass sich das Tippen genau wie im Texteditor Kate anfühlt. Das täuscht nicht. Kile ist die vom KDE-Projekt gepflegte LaTeX-Umgebung, und die Fläche, auf der getippt wird, ist Kates Editorkomponente KatePart, vollständig eingebettet – das Handbuch sagt es wörtlich. Nach derselben Logik zeigt nicht Kile selbst das PDF an, sondern ein eingebettetes Okular. Diese Seite verfolgt jene KDE-Gewohnheit des Zusammensetzens von Komponenten durch Kiles Projekte, sein Werkzeug- und Build-System mit Platzhaltern wie %source und QuickPreview, das eine Auswahl setzt und nur diese zeigt.

Warum sich Kiles Editorfläche wie Kate verhält

Ein Satz aus dem Handbuch erklärt alles: „Kile is based on the Kate editor component, i.e. a lot of its editing capabilities stem from the Kate editor component itself." KDE kennt einen Mechanismus namens KParts, mit dem sich die Komponente einer Anwendung vollständig in eine andere einbetten lässt; Kile setzt damit Kates Editor-Maschine in die Mitte des eigenen Fensters. Deshalb stammen Syntaxhervorhebung, Suchen und Ersetzen, Zeilennummern, Blockauswahl und der Vi-Eingabemodus nicht von Kile, sondern von Kate. Wer Kate zu konfigurieren gewohnt ist, nimmt diese Gewohnheiten unverändert mit. Umgekehrt gilt: Stört etwas an der Editorfläche, ist die Einstellung von KatePart zu ändern, nicht die von Kile.

Darüber legt Kile den Teil, der LaTeX kennt: die automatische Vervollständigung von Umgebungen, die das Paar \begin{...}…\end{...} in einem Zug einsetzt; Paletten, die Zeichen und Auszeichnungen per Klick einfügen; einen QuickStart-Assistenten samt Vorlagen, der \documentclass und das Papierformat in einem einzigen Dialog klärt; sowie die Structure View am linken Rand. Die Strukturansicht ordnet Überschriften, Marken und die eingebundenen Dateien zu einem Baum, und Jump to Structure Element führt zu jedem Eintrag. Die von Kate geerbte Kraft im Umgang mit Text und das von Kile ergänzte Wissen über LaTeX – dieser zweischichtige Aufbau ist Kiles Entwurf.

Diese Bauweise geht auf einen Wechsel um 2003 zurück. Begründet wurde Kile von Pascal Brachet – demselben, der später Texmaker schrieb. Als Jeroen Wijnhout ihn anschrieb, weil er Funktionen beisteuern wollte, übergab Brachet ihm das ganze Projekt. Der nächste Meilenstein unter Wijnhout war Version 1.6, und der Abschnitt „major" ihres Änderungsprotokolls enthält nur zwei Zeilen: „new editor (katepart)" und „project management". Die beiden Säulen also, die Kiles Charakter ausmachen – die von Kate geerbte Editorfläche und das Projekt, das mehrere Dateien bündelt –, kamen in ein und derselben Veröffentlichung. Die Pflege übernahm später ein Team um Michel Ludwig. Am Rande: kile ist norwegisch für „Keil" oder „kitzeln" und wird eher /kiːlə/ ausgesprochen als wie der englische Name Kyle.

Es lohnt, ehrlich zu benennen, wo Kile heute steht. Die Entwicklung läuft weiter, und die Portierung auf KDE Frameworks 6 und Qt 6 ist bereits erledigt – der aktuelle Entwicklungszweig baut gegen Qt 6, KDE Frameworks 6 und Okular 6. Zugleich liegen die Veröffentlichungen sehr weit auseinander: Die letzte stabile Fassung 2.1.3 stammt von 2012, und die Reihe 3.0 steckt noch im Beta-Stadium, mit Beta 1 im Jahr 2017 und Beta 4 im März 2024. Kurz: ein abgehangenes, funktionierendes Werkzeug, kein Editor, der sich monatlich wandelt. Die Lizenz ist GPL v2. Heimat ist der KDE-Desktop unter Linux; da Qt und die KDE-Bibliotheken portiert sind, läuft Kile aber auch unter macOS, BSD und Windows – die Windows-Fassung wird sogar über den Microsoft Store verteilt.

Projekte und Hauptdokument: Kapitel hinzufügen, ohne den Halt zu verlieren

Fasst man mehrere .tex-Dateien zu einem Projekt zusammen, merkt sich Kile, welche davon das Hauptdokument ist. Das Hauptdokument ist die übergeordnete Datei mit \documentclass; ist sie eingetragen, beginnt ein aus einer Kapiteldatei angestoßener Build dennoch beim Hauptdokument. Die mitgelieferten LaTeX-Werkzeuge tragen die Einstellung checkForRoot=yes, sodass Kile bemerkt, wenn eine Datei gesetzt werden soll, die gar nicht die Wurzel eines Dokuments ist. Der Nutzen beschränkt sich nicht auf den Satz: Die Vervollständigung von \ref und \cite greift über sämtliche Dateien des Projekts, sodass sich beim Schreiben von Kapitel 7 eine in Kapitel 2 gesetzte Marke abrufen lässt. Diese Einheit verhindert, dass eine in Kapitel zerlegte Arbeit gerade durch die Zerlegung unhandlich wird.

Werkzeuge und QuickBuild: wie ein Kile-Build zusammengesetzt wird

Ein Kile-Build besteht aus genau einer Sorte Bauteil: dem Werkzeug. pdflatex, dvipdfmx und der PDF-Betrachter sind Werkzeuge derselben Bauform und tragen jeweils eine class, den auszuführenden command, dessen options sowie from/to für die Endungen von Eingabe und Ausgabe. Die Menüs sortieren sie nach Klasse in Build → Compile, Convert und View, und was ein Werkzeug tatsächlich ist, wird unter Settings → Configure Kile... → Tools+Build bearbeitet. Diese Gleichförmigkeit ist Kiles Stärke: Eine neue Umwandlung hinzuzufügen heißt schlicht, ein weiteres Werkzeug anzulegen.

Das mitgelieferte Werkzeug PDFLaTeX führt als Befehl pdflatex und als Optionen -interaction=nonstopmode %source. -synctex=1 fehlt in der Voreinstellung, muss also selbst ergänzt werden, wenn Vorwärts- und Rückwärtssuche genutzt werden sollen – genau dieses Fehlen steckt meist hinter „eingerichtet, aber nichts synchronisiert sich". Dasselbe Werkzeug trägt checkForRoot=yes (prüfen, ob gerade eine Nicht-Wurzeldatei gesetzt wird), jumpToFirstError=yes (zum ersten Fehler springen) und autoRun=yes (selbst entscheiden, ob Hilfsläufe wie BibTeX, makeindex oder Asymptote nötig sind, und sie ausführen). Dank autoRun erfordert ein einfaches Dokument keinerlei Gedanken an Wiederholungsläufe.

-interaction=nonstopmode -synctex=1 %source

Die mit % beginnenden Zeichenfolgen im Optionsfeld sind Kiles Platzhalter; sie werden kurz vor dem Start des Werkzeugs durch die tatsächlichen Werte ersetzt. Am häufigsten greift man zu %source für die verarbeitete Datei und zu %S für denselben Namen ohne Endung; Umwandlungswerkzeuge und externe Betrachter brauchen zusätzlich Platzhalter, die auf die Ausgabeseite zeigen.

Darüber liegt QuickBuild. Es ist kein eigenes Programm, sondern eine Sequence, die Werkzeuge der Reihe nach aufruft; ihr Inhalt ist eine einzige Zeile mit deren Namen, etwa sequence=PDFLaTeX,ViewPDF. Ab Werk gewählt ist PDFLaTeX+ViewPDF – mit pdfLaTeX setzen und das Ergebnis anzeigen. Die mitgelieferten Abfolgen sind unten aufgeführt; die auf ForwardPDF endenden Varianten lassen den Betrachter bei jeder Übersetzung die Seite unter dem Cursor öffnen. Selbstverständlich lassen sie sich umstellen oder um eigene Abfolgen ergänzen.

• PDFLaTeX+ViewPDF – mit pdfLaTeX unmittelbar zum PDF und anzeigen. Die Voreinstellung ab Werk.
• LaTeX+DVItoPDF+ViewPDF – über ein DVI, mit dvipdfmx umgewandelt. Der übliche Weg für japanischen Satz.
• LaTeX+DVItoPS+ViewPS und LaTeX+DVItoPS+PStoPDF+ViewPDF – die Wege über PostScript.
• LuaLaTeX+ViewPDF – mit LuaLaTeX unmittelbar zum PDF und anzeigen.
• PDFLaTeX+ForwardPDF und LuaLaTeX+ForwardPDF – dasselbe, aber mit Vorwärtssuche statt bloßer Anzeige.

Werkzeuge für japanischen Satz: upLaTeX und dvipdfmx

Der langjährige japanische Weg upLaTeX + dvipdfmx nimmt in Kile die Form zweier Werkzeuge an, die zu einer Abfolge verbunden werden. Zuerst das Werkzeug der LaTeX-Familie: Befehl auf uplatex setzen, Optionen wie unten. Dabei -synctex=1 nicht vergessen.

-synctex=1 -interaction=nonstopmode %source

Es folgt das Werkzeug DVItoPDF, das aus dem DVI ein PDF macht. Ab Werk lautet sein Befehl dvipdfmx und seine Optionen %S.dvi; die Angaben from=dvi und to=pdf teilen Kile mit, dass dieser Schritt ein DVI aufnimmt und ein PDF liefert. %S.dvi steht dort, weil auch bei einer Vorlage namens chapter1.tex das zu übergebende Stück chapter1.dvi heißt – genau für dieses Abstreifen und Ersetzen der Endung gibt es %S. Beide Werkzeuge in die Abfolge LaTeX+DVItoPDF+ViewPDF gesetzt, und ein japanisches Dokument entsteht in einem Zug. Der Vollständigkeit halber gehören die Werkzeuge für Literatur und Index auf die japanischtauglichen upbibtex und upmendex umgestellt.

%S.dvi

Sollen Wiederholungsläufe und Abhängigkeiten gründlicher behandelt werden, lautet der übliche Griff: ein Werkzeug hinzufügen, das latexmk aufruft, und QuickBuild aus nichts anderem bestehen lassen. Ein neues Werkzeug mit dem Befehl latexmk und den Optionen unten anlegen. Eine Warnung: Auch latexmk kennt einen Platzhalter %S, und er bedeutet nicht dasselbe wie der von Kile. Die %-Platzhalter in den Werkzeugeinstellungen setzt Kile ein, die %-Platzhalter innerhalb einer .latexmkrc setzt latexmk ein. Beides sind verschiedene Sprachen und gehören nicht vermischt. Die Konfiguration von latexmk selbst behandelt eine andere Seite.

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

Zusammenspiel mit Okular: Vorwärts- und Rückwärtssuche einrichten

Nach derselben Logik, die KatePart in die Editorfläche brachte, zeigt eine Komponente des KDE-Standardbetrachters Okular das PDF an. Alle Anzeigewerkzeuge stehen ab Werk auf Document Viewer – also auf einem Okular, das im Fenster von Kile wohnt –, wobei sich auch Einstellungen wählen lassen, die den eigenständigen Befehl okular in einem separaten Fenster aufrufen. Dass Quelltext und PDF nebeneinander in einem Fenster liegen, ist eine Folge dieser Einbettung, und ebenso das flüssige Hin und Her.

Vorwärtssuche und bloßes Anzeigen sind zwei verschiedene Werkzeuge; ihre Verwechslung ist der Grund, warum eine abgeschriebene Konfiguration nicht greift. Das reine ViewPDF übergibt Okular lediglich %target (oder --unique %target), während ForwardPDF für die Vorwärtssuche --unique %absolute_target übergibt. Erst %absolute_target trägt die zur eigenen Zeile gehörende Position im Ausgabe-PDF, und deshalb kann Okular beim Absatz unter dem Cursor aufschlagen. Der häufige Irrtum besteht darin, %target im Feld ViewPDF stehen zu lassen und sich dann über die wirkungslose Vorwärtssuche zu wundern; zu ändern ist die Seite von ForwardPDF, und die QuickBuild-Abfolge sollte auf ForwardPDF enden.

Die Rückwärtssuche wird auf der Seite von Okular eingerichtet, nicht in Kile. In Okulars Einstellungen den Editor auf Kile setzen und als Startbefehl kile --line %l eintragen; ein Klick bei gedrückter Umschalttaste im PDF führt dann zur entsprechenden Zeile in Kile zurück. Die Vorwärtssuche läuft von Kile zu Okular, die Rückwärtssuche von Okular zu Kile – wer sich merkt, dass die Richtung bestimmt, wo die Einstellung wohnt, kommt nicht durcheinander. Was der Synchronisationsmechanismus tatsächlich speichert – was in einer .synctex.gz steckt – behandelt eine eigene Seite.

QuickPreview: nur den ausgewählten Teil setzen

QuickPreview erspart den vollständigen Neuaufbau, wenn in einem langen Dokument nur eine einzige Formel geändert wurde. Es hüllt allein die Auswahl in ein kleines Wegwerfdokument, verarbeitet dieses und zeigt das Ergebnis. Für den Ausschnitt gibt es vier Möglichkeiten: die Auswahl selbst, die eine Umgebung, in der der Cursor steht (der Inhalt eines \begin{...}…\end{...}), ein einzelnes über \input eingebundenes Teildokument sowie die Formelgruppe um den Cursor. Das Ergebnis lässt sich statt in einem eigenen Fenster auch in einer Leiste am unteren Rand anzeigen, sodass beim Feilen an einer Tabelle oder einer langen Gleichung die Wartezeit eines ganzen Builds entfällt. Dahinter laufen eigene Vorschauwerkzeuge (class=LaTeXpreview), womit die echten Build-Einstellungen unberührt bleiben.

Was am ersten Tag mit Kile zu klären ist

Zuerst zu klären ist nicht, was die Schaltflächen bedeuten, sondern was in QuickBuild kommt. Für überwiegend westlichen Text bleibt die Voreinstellung PDFLaTeX+ViewPDF unangetastet; für japanische upLaTeX-Arbeiten wird LaTeX+DVItoPDF+ViewPDF gewählt; und wenn Literatur- und Indexläufe verlässlich sein müssen, steht dort ein einziges latexmk-Werkzeug. Ist das früh geklärt, übersteht der Ablauf – aus einer Kapiteldatei starten und stets das Hauptdokument bauen – jede später hinzugefügte Kapiteldatei. Das Handbuch nennt Alt+2 als Tastenkürzel zum Übersetzen des Quelltexts und hält fest, dass der Betrachter Okular beim Ausführen von QuickBuild von selbst starten sollte.

Sind die Einstellungen stabil, ein kurzes main.tex als Projekt eintragen und einmal prüfen, dass ein Build aus einer Kapiteldatei weiterhin das Hauptdokument erzeugt. Tritt ein Fehler auf, das .log über View logfile öffnen und mit Next error weitergehen – zum ersten Fehler führt jumpToFirstError=yes bereits von selbst. Wer diesen Weg einmal in einem Zug abgeht, bis hin zur funktionierenden Vorwärtssuche in Okular, muss danach nur noch Kapitel hinzufügen.