Kile

打开 Kile 后最先察觉到的，是敲字的手感和文本编辑器 Kate 一模一样。这不是错觉。Kile 是 KDE 项目维护的 LaTeX 集成环境，而你输入文字的那块面板，正是把 Kate 的编辑部件 KatePart 整个嵌了进来——手册里就是这么写的。按同样的道理，显示 PDF 的也不是 Kile 自己，而是嵌进来的 Okular。本页顺着这种 KDE 式的「拼装部件」思路，依次看它如何体现在 Kile 的 项目、以 %source 打头的置换记号所构成的 工具与构建机制，以及只排版选中部分并展示出来的 QuickPreview 上。

Kile 的编辑面为什么像 Kate

手册里的一句话就把一切说清了：「Kile is based on the Kate editor component, i.e. a lot of its editing capabilities stem from the Kate editor component itself.」 KDE 有一套叫 KParts 的机制，能把一个应用的部件整个嵌进另一个应用里，Kile 正是用它把 Kate 的编辑引擎放到了自己窗口的中心。所以语法高亮的定义、查找替换、行号、块选择、Vi 输入模式这些编辑行为，都不是 Kile 自己写的，而是从 Kate 继承来的。习惯了 Kate 的配置，这些习惯可以直接带过来。反过来说，对编辑面的脾气不满意时，该改的是 KatePart 的设置，而不是 Kile 的。

在这之上，Kile 自己叠加的是「懂 LaTeX」的那一半：一次补出 \begin{...}…\end{...} 配对的 环境自动补全；点一下就插入符号与标签的调色板；把 \documentclass 与纸张尺寸放在一个对话框里定下的 QuickStart 向导 和若干模板；以及左侧的 结构视图（Structure View）。结构视图把标题、标签和被引入的文件排成一棵树，用 Jump to Structure Element 就能跳到其中任意一处。从 Kate 继承来的「处理文字的能力」，加上 Kile 自己添的「理解 LaTeX 的能力」——这两层结构本身就是 Kile 的设计。

这套结构，起于 2003 年前后的一次交接。创立 Kile 的是 Pascal Brachet——后来写出 Texmaker 的那个人。当 Jeroen Wijnhout 写信说想添些功能时，Brachet 把整个项目交给了他。Wijnhout 手上的下一个节点是 1.6 版，而这一版变更记录的「major（重大变更）」栏只有两行：「new editor (katepart)」和「project management」。也就是说，决定 Kile 性格的两根支柱——承自 Kate 的编辑面，和把多个文件拢在一起的项目——是在同一次发布里一起进来的。此后的维护由 Michel Ludwig 领衔的团队接手。顺带一提，kile 在挪威语里是「楔子」「呵痒」的意思，读音更接近 /kiːlə/，而不是英文名 Kyle。

Kile 眼下的处境，值得如实看待。开发仍在继续，向 KDE Frameworks 6 与 Qt 6 的移植也已完成——当前开发分支的构建要求是 Qt 6、KDE Frameworks 6 和 Okular 6。但另一面是，发布的间隔非常长：最后一个稳定版 2.1.3 出自 2012 年，下一代的 3.0 系至今仍在 beta，beta 1 是 2017 年，beta 4 是 2024 年 3 月。一句话：这是一件成熟可用的工具，而不是每月都在变的编辑器。许可证是 GPL v2。它的主场是 Linux 上的 KDE 桌面，但由于 Qt 和 KDE 的库已被移植，它在 macOS、BSD 和 Windows 上也能跑（Windows 版还通过 Microsoft Store 分发）。

项目与主文档——章节再多也不会迷路

把多个 .tex 归入一个项目，Kile 就会记住其中哪一个是主文档。 主文档就是持有 \documentclass 的那个父文件；登记之后，即使从子文件发起构建，起点也始终是主文档。自带的 LaTeX 工具里带着 checkForRoot=yes 这项设置，因此当你要排版的文件根本不是文档的根时，Kile 能够察觉。项目的好处不止于排版：\ref 与 \cite 的补全会横跨项目内的所有文件，于是写第 7 章时也能唤出第 2 章打下的标签。正是这个单位，让按章拆分的论文或书籍不至于因为「拆开了」而变得难用。

工具与 QuickBuild——Kile 的构建是怎样搭起来的

Kile 的构建只由一种部件组成：工具（Tools）。 pdflatex、dvipdfmx 和 PDF 阅读器都是同一形制的工具，各自带有 class（类别）、要执行的 command、options（参数），以及说明输入输出扩展名的 from／to。菜单按类别把它们分到 Build → Compile／Convert／View，而具体内容则在 Settings → Configure Kile... → Tools+Build 里编辑。这种一致性正是 Kile 的长处：想加一种新的转换，无非是再造一个工具而已。

出厂状态的 PDFLaTeX 工具，命令是 pdflatex，选项是 -interaction=nonstopmode %source。-synctex=1 默认并不在里面，所以打算用正向／反向搜索的话得自己加上——「明明配置了却不同步」的原因，多半就在这里。同一个工具还带着 checkForRoot=yes（确认你不是在排一个非根文件）、jumpToFirstError=yes（跳到第一个错误处）和 autoRun=yes（自行判断是否需要 BibTeX、makeindex、Asymptote 之类的辅助处理并运行）。有了 autoRun，简单文档就不必操心重跑几次。

-interaction=nonstopmode -synctex=1 %source

选项栏里那些以 % 开头的记号是 Kile 的置换记号，会在工具启动前的一刻换成实际值。最常用的是指代处理对象本身的 %source，以及去掉扩展名的 %S；而调用转换工具或外部阅读器时，还需要指向输出一侧的记号。

架在这之上的是 QuickBuild。它不是独立的程序，而是一条按顺序调用工具的「序列（Sequence）」，内容不过是像 sequence=PDFLaTeX,ViewPDF 这样把工具名排成一行。出厂选中的是 PDFLaTeX+ViewPDF，也就是「用 pdfLaTeX 排版，然后直接显示」。自带的序列如下；以 ForwardPDF 结尾的那几个，会在每次编译时让阅读器打开光标所在的页面。当然，你也可以自行重排，或添加新的序列。

• PDFLaTeX+ViewPDF —— 用 pdfLaTeX 直接生成 PDF 并显示。出厂默认。
• LaTeX+DVItoPDF+ViewPDF —— 经由 DVI，用 dvipdfmx 转换。日文的经典路线。
• LaTeX+DVItoPS+ViewPS 与 LaTeX+DVItoPS+PStoPDF+ViewPDF —— 中途经过 PostScript 的路线。
• LuaLaTeX+ViewPDF —— 用 LuaLaTeX 直接生成 PDF 并显示。
• PDFLaTeX+ForwardPDF 与 LuaLaTeX+ForwardPDF —— 同上，但以带正向搜索的方式打开，而非单纯显示。

日文的工具设置（upLaTeX 与 dvipdfmx）

日文长期以来的定番 upLaTeX + dvipdfmx，在 Kile 里表现为「改两个工具、拼成一条序列」。 先从 LaTeX 系的工具入手：把命令设为 uplatex，选项写成下面这样。别忘了在这里加上 -synctex=1。

-synctex=1 -interaction=nonstopmode %source

接下来是把 DVI 转成 PDF 的 DVItoPDF 工具。它出厂时的命令就是 dvipdfmx，选项是 %S.dvi；而 from=dvi 与 to=pdf 这两项声明，正是告诉 Kile「这一步吃 DVI、吐 PDF」。之所以写成 %S.dvi，是因为哪怕原稿是 chapter1.tex，要交给它的也是 chapter1.dvi——去掉扩展名再换一个，正是 %S 的用处。把这两个工具放进 LaTeX+DVItoPDF+ViewPDF 序列，日文文档就能一步构建完成。为求周全，也把参考文献与索引工具改指向支持日文的 upbibtex 和 upmendex。

%S.dvi

若希望重跑次数和依赖关系被照料得更彻底，惯常做法是新增一个调用 latexmk 的工具，并让 QuickBuild 只剩它一个。新建工具，命令填 latexmk，选项填下面这行。有一点要当心：latexmk 里也有一个叫 %S 的记号，含义与 Kile 的并不相同。 写在工具设置栏里的 % 记号由 Kile 展开，写在 .latexmkrc 里的 % 记号由 latexmk 展开。请把它们当成两种语言，不要混用。latexmk 自身的配置是另一页的主题。

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

与 Okular 的联动——正向搜索与反向搜索的设置

与把 KatePart 嵌进编辑区同一个道理，显示 PDF 的也是 KDE 标准文档阅读器 Okular 的部件。各个查看类工具的出厂默认都是 Document Viewer——也就是住在 Kile 窗口里的那个 Okular；当然也可以选择调用独立窗口的 okular 命令。源码与 PDF 能并排在同一个窗口里，正是这种嵌入的结果，来回切换之所以顺滑也源于此。

正向搜索和单纯显示是两个不同的工具，弄混了，照抄配置也不会奏效。 只负责显示的 ViewPDF 交给 Okular 的不过是 %target（或 --unique %target），而用于正向搜索的 ForwardPDF 交的是 --unique %absolute_target。正是 %absolute_target 里带着「对应输出 PDF 里哪一行的位置」，Okular 才能翻到光标所在的段落。常见的错位是：把 %target 留在 ViewPDF 栏里，然后困惑为什么正向搜索毫无反应；该改的是 ForwardPDF 那边，并把 QuickBuild 序列的末尾换成 ForwardPDF。

反向搜索是在 Okular 那边设置的，而不是在 Kile 里。 在 Okular 的设置中把编辑器设为 Kile，启动命令写成 kile --line %l；此后在 PDF 上按住 Shift 单击某处，就能回到 Kile 里对应的行。正向搜索是 Kile → Okular，反向搜索是 Okular → Kile，记住「方向决定设置在哪一侧」，就不会绕弯路。至于同步机制本身究竟存了什么——.synctex.gz 里面装的是什么——由另一页讲述。

QuickPreview——只排你选中的那一段

QuickPreview 的存在，是为了免去「长文档里只改了一条公式却要整篇重排」的浪费。 它把你选中的部分裹进一个小小的临时文档去处理，再把结果给你看。取范围的方式有四种：选中区域本身、光标所在的单个环境（\begin{...}…\end{...} 的内容）、由 \input 引入的单个子文档，以及光标所在的一组公式。结果还可以显示在窗口下方的条里而不是另开窗口，于是在打磨表格或长公式外观时，整整一次构建的等待就此消失。背后跑的是专用的预览工具（class=LaTeXpreview），因此不会弄脏正式的构建设置，这点也让人放心。

开始用 Kile 的第一天该定下什么

第一件要定下的事，不是各个按钮什么意思，而是「QuickBuild 里放什么」。 以西文为主就保留默认的 PDFLaTeX+ViewPDF；日文的 upLaTeX 稿子选 LaTeX+DVItoPDF+ViewPDF；若要确保参考文献和索引都跑到，就只放一个 latexmk 工具。先把这件事办妥，之后往项目里添章节文件时，「从子文件启动、始终构建主文档」这条流程也不会散架。手册给出的编译源码快捷键是 Alt+2，并说运行 QuickBuild 时 Okular 阅读器应当自动启动。

设置稳定之后，把一个短短的 main.tex 注册成项目，确认一次「从子文件构建仍然产出主文档」。出错时，用 View logfile 打开 .log，再用 Next error 往下走——多亏 jumpToFirstError=yes，第一个错误处会自动跳到。若能把这条路一口气走通，直到 Okular 的正向搜索也正常，接下来就只剩添章节了。