Kile

The first thing you notice on opening Kile is that typing in it feels exactly like typing in the Kate text editor. That is not an illusion. Kile is the LaTeX environment the KDE project maintains, and the surface you type on is Kate’s editing component, KatePart, embedded whole — the handbook says so in as many words. By the same logic, what displays the PDF is not Kile itself but an embedded copy of Okular. This page follows that KDE habit of assembling components through Kile’s projects, its tool and build system with placeholders such as %source, and QuickPreview, which typesets a selection and shows you just that.

Why Kile’s editing surface behaves like Kate

One sentence in the handbook explains everything: “Kile is based on the Kate editor component, i.e. a lot of its editing capabilities stem from the Kate editor component itself.” KDE has a mechanism called KParts that lets one application’s component be embedded whole inside another, and Kile uses it to place Kate’s editing engine at the centre of its own window. That is why the syntax-highlighting definitions, search and replace, line numbers, block selection, and the Vi input mode are not things Kile wrote but things it inherits from Kate. If you are used to configuring Kate, the habits carry straight over. Put the other way round: when something about the editing surface annoys you, the setting to change is KatePart’s, not Kile’s.

What Kile lays on top is the part that knows LaTeX: auto-completion of environments, which drops in the matching \begin{...}…\end{...} pair in one go; palettes that insert symbols and tags with a click; a QuickStart wizard and a set of templates that settle \documentclass and the paper size in a single dialogue; and the Structure View on the left. The structure view arranges headings, labels, and the files being pulled in into one tree, and Jump to Structure Element takes you to any of them. The power to handle text, inherited from Kate, and the knowledge of LaTeX, added by Kile — that two-layer arrangement is Kile’s design.

That architecture came out of a handover around 2003. Kile was founded by Pascal Brachet — the same person who would later write Texmaker. When Jeroen Wijnhout wrote to him wanting to contribute features, Brachet passed him the whole project. The next milestone under Wijnhout was version 1.6, and the “major” section of its changelog has just two lines: “new editor (katepart)” and “project management.” The two pillars that define Kile’s character — an editing surface inherited from Kate, and a project that gathers several files — therefore arrived in the same single release. Maintenance later passed to a team led by Michel Ludwig. Incidentally, kile is Norwegian for “wedge” or “tickle,” and is pronounced closer to /kiːlə/ than to the English name Kyle.

It is worth being straight about where Kile stands today. Development continues, and the port to KDE Frameworks 6 and Qt 6 is already done — the current development branch builds against Qt 6, KDE Frameworks 6, and Okular 6. At the same time, releases are very far apart: the last stable version, 2.1.3, dates from 2012, and the 3.0 line is still in beta, with beta 1 in 2017 and beta 4 in March 2024. In short, this is a settled tool that works, not an editor that changes monthly. The licence is GPL v2. Its home ground is the KDE desktop on Linux, but because Qt and the KDE libraries are ported elsewhere it also runs on macOS, BSD, and Windows — the Windows build is even distributed through the Microsoft Store.

Projects and the master document: adding chapters without losing your footing

Group several .tex files into one project and Kile remembers which of them is the master document. The master is the parent that holds \documentclass; once it is registered, a build started from a child file still begins at the master. The stock LaTeX tools carry a setting called checkForRoot=yes, so Kile can notice when you are about to typeset a file that is not the root of a document at all. The payoff is not confined to typesetting: completion for \ref and \cite reaches across every file in the project, so you can call up a label you set in chapter 2 while writing chapter 7. This is the unit that keeps a thesis or a book from becoming harder to work with merely because it was split into chapters.

Tools and QuickBuild: how a Kile build is assembled

A Kile build is made of exactly one kind of part: the tool. pdflatex, dvipdfmx, and the PDF viewer are all tools of the same shape, each carrying a class, a command to run, its options, and from/to extensions saying what it consumes and produces. The menus sort them by class into Build → Compile, Convert, and View, and you edit what each one actually is under Settings → Configure Kile... → Tools+Build. That uniformity is Kile’s strength: adding a new conversion means nothing more than creating one more tool.

The PDFLaTeX tool as shipped has pdflatex for its command and -interaction=nonstopmode %source for its options. -synctex=1 is not there by default, so you have to add it yourself if you intend to use forward and inverse search — that omission is the usual cause of “I configured it but nothing synchronises.” The same tool carries checkForRoot=yes (verify you are not typesetting a non-root file), jumpToFirstError=yes (jump to the first error), and autoRun=yes (decide for itself whether auxiliary passes such as BibTeX, makeindex, or Asymptote are needed, and run them). Because of autoRun, a straightforward document needs no thought about reruns.

-interaction=nonstopmode -synctex=1 %source

The %-prefixed tokens you can write in the options field are Kile’s placeholders, replaced with real values just before the tool starts. The two you reach for most are %source, which names the file being processed, and %S, the same name with the extension dropped; conversion tools and external viewers also need tokens that point at the output side.

On top of that sits QuickBuild. It is not a program of its own but a Sequence that calls tools in order, and its content is a single line naming them, such as sequence=PDFLaTeX,ViewPDF. The one selected out of the box is PDFLaTeX+ViewPDF — typeset with pdfLaTeX, then display the result. The sequences that ship are listed below; the variants ending in ForwardPDF make the viewer open the page under your cursor on every compile. You are of course free to rearrange them or add sequences of your own.

• PDFLaTeX+ViewPDF — straight to a PDF with pdfLaTeX, then display it. The shipped default.
• LaTeX+DVItoPDF+ViewPDF — via a DVI, converted with dvipdfmx. The standard route for Japanese.
• LaTeX+DVItoPS+ViewPS and LaTeX+DVItoPS+PStoPDF+ViewPDF — the routes that pass through PostScript.
• LuaLaTeX+ViewPDF — straight to a PDF with LuaLaTeX, then display it.
• PDFLaTeX+ForwardPDF and LuaLaTeX+ForwardPDF — the same, but opening with forward search instead of plain display.

Configuring tools for Japanese: upLaTeX and dvipdfmx

The long-standing Japanese route, upLaTeX + dvipdfmx, takes the shape of two tools joined into one sequence in Kile. Start with the LaTeX-family tool: set its command to uplatex and its options as below. Do not forget to put -synctex=1 in here.

-synctex=1 -interaction=nonstopmode %source

Next comes the DVItoPDF tool that turns the DVI into a PDF. As shipped its command is dvipdfmx and its options are %S.dvi, and the declarations from=dvi and to=pdf are what tell Kile this is the step that consumes a DVI and produces a PDF. The reason to write %S.dvi is that even when the original was chapter1.tex, what must be handed over is chapter1.dvi — dropping the extension and attaching a new one is exactly what %S is for. Put the two tools into the LaTeX+DVItoPDF+ViewPDF sequence and a Japanese document builds in one stroke. For completeness, point the bibliography and index tools at the Japanese-aware upbibtex and upmendex.

%S.dvi

If you want rerun counts and dependencies handled more thoroughly, the standard move is to add one tool that calls latexmk and make QuickBuild consist of nothing else. Create a new tool with the command latexmk and the options below. One caution: latexmk has a token called %S too, and it does not mean what Kile’s does. The % tokens written in a tool’s settings are expanded by Kile; the % tokens written inside a .latexmkrc are expanded by latexmk. Treat them as two different languages and do not mix them. Configuring latexmk itself is the subject of another page.

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

Working with Okular: setting up forward and inverse search

By the same logic that put KatePart in the editing area, what displays the PDF is a component of KDE’s standard document viewer, Okular. Every viewing tool ships defaulting to Document Viewer — that is, an Okular living inside Kile’s own window — though settings that call the separate okular command in its own window are available too. Source and PDF sitting side by side in one window is a consequence of that embedding, and so is how smooth the back-and-forth feels.

Forward search and plain viewing are two different tools, and mixing them up is why a copied configuration fails to work. The view-only ViewPDF just hands Okular %target (or --unique %target), while the forward-search ForwardPDF hands it --unique %absolute_target. It is %absolute_target that carries the position in the output PDF corresponding to your line, which is what lets Okular open at the paragraph under your cursor. The common mix-up is to leave %target in the ViewPDF field and then wonder why forward search does nothing; the fix is on the ForwardPDF side, plus ending your QuickBuild sequence with ForwardPDF.

Inverse search is configured on the Okular side, not in Kile. In Okular’s settings, set the editor to Kile with the launch command kile --line %l; then Shift-clicking a spot in the PDF takes you back to the corresponding line in Kile. Forward search runs Kile → Okular and inverse search runs Okular → Kile, so remembering that the direction determines where the setting lives will keep you out of trouble. What the synchronisation mechanism actually stores — what is inside a .synctex.gz — is covered on its own page.

QuickPreview: typesetting only the part you selected

QuickPreview exists to spare you a full rebuild when all you changed was one formula inside a long document. It wraps just your selection in a small throwaway document, processes that, and shows you the result. There are four ways to choose the region: the selection itself, the single environment the cursor sits in (the body of a \begin{...}…\end{...}), a single subdocument pulled in with \input, and the mathgroup around the cursor. The result can appear in a bar along the bottom of the window rather than a separate one, so while tuning the look of a table or a long equation the wait for a whole build simply disappears. Dedicated preview tools (class=LaTeXpreview) run behind it, which means your real build settings stay untouched.

What to settle on your first day with Kile

The first thing to settle is not what the buttons mean but what goes into QuickBuild. For mostly Western text, leave the default PDFLaTeX+ViewPDF alone; for Japanese upLaTeX work, choose LaTeX+DVItoPDF+ViewPDF; and if the bibliography and index passes must be reliable, make it a single latexmk tool. Settle that first and the flow — start from a child file, always build the master — survives every chapter file you later add to the project. The handbook gives Alt+2 as the keyboard shortcut for compiling your source, and notes that running QuickBuild should launch the Okular viewer by itself.

Once the settings are stable, register a small main.tex as a project and confirm just once that building from a child file still produces the master. When an error appears, open the .log through View logfile and step onward with Next error — jumpToFirstError=yes already takes you to the first one. If you can walk that whole path in one go, right through to Okular’s forward search working, all that is left is to add chapters.