第一次看到“caveman”这个词，我脑子里跳出的是石器时代拿着棍子追野猪的画面，接着想到的是程序员圈里那个“原始人调试法”——不整花活，先用最朴素的打印输出把逻辑跑通再说。后来在Emacs的配置社区里频繁碰到这个词，才发现它还有另一层身份：一个专门负责代码语法高亮的包名，而且不少人已经把它当成了整理高亮规则的默认选择。
这篇东西想聊的就是这个caveman：它到底是什么，为什么会在Emacs生态里被频繁提及，三种高亮实现——tree-sitter、Vim风格正则、声明式规则——各自适合什么场景，以及我在实际配置和迁移规则时踩过的坑。适合正在折腾Emacs外观、想把语法高亮做到“够用又不折腾”的人，也适合那些从别的编辑器迁过来、看着一堆高亮规则就头疼的配置党。
1. 为什么到处都在提caveman，它到底做了什么
先说结论：caveman是一个面向Emacs的语法高亮管理工具，它把原本散落在各个major mode里的高亮逻辑收敛到一个统一入口。你不需要在rust-ts-mode里配一遍rust的高亮，在rust-mode里再配一遍，到其他支持tree-sitter的模式里还要再维护一份——这些事caveman帮你集中处理。
跟EditorConfig解决“不同编辑器缩进不一致”的思路很像，caveman解决的是“高亮规则重复散落”的问题。一个项目里大家的缩进统一靠.editorconfig，那语法高亮能不能也统一靠一份声明式配置？caveman的想法就是：可以。
1.1 输出太分散，才是真痛点
在Emacs里，语法高亮传统上靠font-lock体系完成。每个major mode自己定义一组keywords正则，再用font-lock-add-keywords注册进去。这本身没什么问题，问题出在“分散”上：
- 每种语言的高亮逻辑都写在自己的mode文件里，想改样式得翻不同包的源码；
- 新的tree-sitter语法解析已经逐步普及，但是各个mode接入的进度参差不齐，有的用ts模式，有的还在旧的regex模式；
- 遇到几种语言混写的文件，比如HTML里嵌JavaScript，高亮规则经常互相干扰。
我自己最早碰到这问题，是在维护一个老项目的时候。项目里有TypeScript、CSS、HTML，还有一堆自定义配置文件。每个文件的高亮表现都不一样，同一个关键词在A文件里是蓝色，在B文件里变成了绿色，当时唯一的解决办法就是给每个mode手动加font-lock规则，改得越多越乱。
caveman就是针对这种混乱状态设计的：它提供一套中立的规则描述方式，再配上一套与tree-sitter grammar对接的机制。你写一份规则，它负责映射到具体editor的font-lock机制里，高亮马上就能用。这套思路对大项目、多语言项目尤其友好，因为规则可以随项目走，而不是绑死在某个mode包上。
1.2 为什么叫这么不正经的名字
我一开始以为这是个搞笑项目，看了文档才知道名字本身就是对设计哲学的描述。作者想表达的核心是：高亮规则不应该过度设计，先用最简单直接的方式把颜色弄对，这就是“穴居人”风格——不搞复杂的框架，不引入抽象层，直接告诉编辑器“这种token给我染成红色、那种染成蓝色”。
这个思路和社区里常说的caveman debugging一脉相承。所谓caveman debugging就是优先用最原始的手段定位问题，比如加打印、加日志、最小化复现，而不是一上来就挂调试器、上APM。caveman这个项目继承了同一个气质：能用声明式规则说清楚的，绝不写一堆elisp函数；能用正则解决的，绝不强制每次解析都跑完整AST。
这种克制的设计在Emacs插件里挺难得。很多包第一版写完就想着加各种feature，而caveman始终守着“高亮这点事别搞太复杂”的底线，实际用起来也确实比那些又大又全的方案好维护得多。
2. 三种高亮机制的边界，选错了才是真正的坑
caveman最需要花时间理解的部分，就是它支持三套高亮实现：tree-sitter、Vim风格正则、声明式规则。很多人以为这三者是“选一个用”的关系，其实它们是分工关系。
| 实现方式 | 精确度 | 性能开销 | 维护成本 | 适用场景 |
|---|---|---|---|---|
| tree-sitter | 高，基于AST节点 | 初次解析较高，后续增量 | 需要匹配grammar版本 | 主流语言、嵌套复杂的代码 |
| Vim正则 | 中等，依赖编写水平 | 低 | 正则写久了自己都看不懂 | 简单DSL、Markdown、配置文件 |
| 声明式规则 | 中低，靠节点类型匹配 | 最低 | 几乎零维护 | 自定义小语言、快速验证 |
2.1 tree-sitter精确，但绑版本是绕不开的代价
tree-sitter的工作原理是把源码parse成一棵具体的语法树，高亮的时候不是靠正则去猜，而是直接读取AST节点，所以它在处理注释、字符串、嵌套语法时有天然优势。比如一个字符串里面出现了"//"，正则方案会把后面的内容误判成注释，但tree-sitter知道那还是在字符串内部。
代价就是版本绑定。tree-sitter每次解析都需要对应语言的grammar库，而grammar库更新很频繁，今天装的和明天装的可能就不是一个版本，高亮结果也会跟着变。之前我给一个项目配Rust高亮，grammar升了一个小版本之后，所有if、loop都失去了关键词颜色，排查了半天才发现是tree-sitter-rust的节点类型命名改了，capture没对上。
所以用tree-sitter方案时，我一般会在项目里锁住grammar的commit版本，避免顶着头条更新跑。这一点后面装环境时还会细说。
2.2 Vim正则稳，但真的会“顺藤摸瓜摸到沟里”
Vim风格正则是给有Vim迁移习惯的人准备的。它的好处在于配置方式直观，一行命中的区域就直接染色，不需要额外依赖tree-sitter grammar。很多老配置、嵌入式开发环境、或者不想引入太重依赖的人会优先选它。
但它最大的问题也和正则本身的特性有关：容易跨行误匹配。一个正则匹配上了，highlight范围可能从行首一路延伸到文件末尾，这种“顺藤摸瓜摸到沟里”的现象，我在Markdown代码块里遇得最多。代码块里的反引号、缩进内容，如果正则写得不够精细，整个文档后半部分会被染成同一种颜色，那种视觉冲击真的让人瞬间不想再调了。
2.3 声明式越简单，能力上限越明显
声明式规则是三套里最好上手的，甚至不需要懂正则，只需要把token类型和face对应起来就行。它适合什么场景呢？比如你写了一个内部配置文件，格式就几种：键、值、注释、布尔值。你拿tree-sitter去解析这种文件纯属杀鸡用牛刀，用声明式规则五秒钟就能配完。
但如果你想高亮一门像C++那样需要前置声明、模板、重载的语言，声明式规则就完全不够用了，因为它几乎没有上下文感知能力。所以我的建议是：小语言、配置文件、DSL优先用声明式；正统编程语言优先用tree-sitter；在老环境里保底用正则。
3. 动手装一回：环境准备和基础配置
我做过的很多次迁移经历都指向同一件事——大部分caveman配置问题不是出在规则上，而是出在环境版本上。版本不对，高亮就是不出，这条经验是铁的。
3.1 最小配置清单
用use-package管理的话，最小配置大概是这个样子：
(use-package caveman :ensure t :defer t :custom (caveman-auto-detect-grammar t) (caveman-fallback-highlighting 'vim-regex) :hook (prog-mode . caveman-mode))我的习惯是先把默认mode钩子挂上，让所有prog-mode都自动激活caveman，然后再针对特定语言关掉或微调。比如某些语言我已经有定制得很精细的原生mode，就不希望caveman再插手，那就单独加一条(text-mode . (lambda () (caveman-mode -1)))。
依赖方面，如果只使用声明式和正则，一个普通Emacs就够了。如果使用tree-sitter方案，需要确保Emacs版本里带有tree-sitter支持，同时装好对应语言的grammar：
# 以Rust为例，手动编译tree-sitter grammar git clone https://github.com/tree-sitter/tree-sitter-rust cd tree-sitter-rust cargo build --release cp target/release/librust.so ~/.emacs.d/tree-sitter/这里我强烈建议把grammar的commit记录一下。比如写进一个requirements文件或一个Makefile里，不然几个月之后重新配环境，高亮规则会因为grammar版本漂移而变得不可复现。
3.2 装完先别急着写规则，验证一下
安装完第一件事不是写规则，而是验证基础功能有没有生效。我会做三个检查：
- 打开一个支持的语言文件，
M-x caveman-mode确认mode状态是开启的； - 把光标移到某个字符串或注释上，用
describe-char看face值，确认它是caveman设置的face而不是原生mode的face； - 临时改一份规则文件，revert一下当前buffer，看看高亮有没有跟着变。
这三步如果在五分钟内全部通过，基本可以确定是环境问题之外的规则问题了。很多时候装完看起来“没反应”，其实是caveman的face被原生theme的face覆盖了，这时候加一行：
(defface caveman-function-name-face '((t (:foreground "#d19a66" :weight bold))) "Face for function names.")然后指定theme使用这个face即可。记住：caveman的定位是高亮规则管理，不是颜色主题。它负责告诉你哪一段是什么类型的token，但最终显示成什么颜色，是theme决定的。这两层别搞混。
4. 把高亮规则写明白：一眼就懂的语言配置文件
接下来说重头戏——规则怎么写。caveman的规则文件把每种语言的高亮定义成一张表，每行一个pattern，告诉caveman“什么类型的token该用哪个face”。我用一个自创的小配置语言来演示，它只有字符串、注释、关键字、数字、函数名这五类token。
4.1 一份最小可用的规则文件示例
我习惯用TOML来组织规则，因为它层级清晰，写起来不折腾。结构大致是这样：
[language] name = "mapc" extensions = [".mapc"] [[rules]] type = "string" pattern = "\"[^\"]*\"" face = "font-lock-string-face" [[rules]] type = "comment" pattern = "#.*$" face = "font-lock-comment-face" [[rules]] type = "keyword" pattern = "\\b(if|else|for|while|return)\\b" face = "font-lock-keyword-face" [[rules]] type = "number" pattern = "\\b[0-9]+\\b" face = "font-lock-constant-face" [[rules]] type = "function" pattern = "^[a-zA-Z_][a-zA-Z0-9_]*\\s*\\(" face = "font-lock-function-name-face"这里面的type、pattern、face字段对应的意思分别是：
type：规则的类型标识，用来和tree-sitter的capture做映射时用；pattern：正则表达式，决定哪些文本会被识别出来；face：高亮使用的face名称，这里是Emacs内置的font-lock系列face。
如果你用的是tree-sitter方案而不是正则方案，那pattern字段可以留空，改成capture字段，指向对应语言的tree-sitter capture名字。比如r语言里一切是@string，你直接映射到font-lock-string-face就完事。
4.2 pattern匹配顺序和优先级
初学者最容易忽略的就是顺序问题。规则是从上到下逐条匹配的，后面的规则会覆盖前面的规则。比如上面示例里，number规则写在keyword规则后面，那么一个叫“if1”的标识符（如果正则能匹配上）会先被keyword规则染成关键字颜色，再被number规则尝试覆盖。
实战里我习惯把最长的、最具体的规则放前面，短的、泛的规则放后面。注释规则如果放太靠后，很可能被字符串规则吃掉，导致注释颜色永远不出现。
另外，不建议把正则规则写得太过宽泛，尤其是.*这种东西。一条.*规则能匹配一大片，轻则高亮无意义，重则把整个文件刷成同色。写正则的时候多锚定行首行尾，多用\b做边界，比事后加补充规则省太多事。
5. 从Vim正则迁移，或者把tree-sitter capture映射好，二者怎么对齐
5.1 Vim正则与Emacs方言的差异对照
如果你是从Vim迁到Emacs，最痛苦的就是正则方言差异。caveman支持Vim风格正则，但跑到Emacs环境里还是有一层转换，常见差异如下：
| Vim正则写法 | 含义 | Emacs/caveman对应写法 |
|---|---|---|
\v | very magic模式 | 一般不需要，直接写 |
\V | very nomagic模式 | 全部字面匹配，Emacs用\=做不到，需手动转义 |
\zs\ze | 设定匹配区域起点和终点 | 用\\(...\\)分组替代 |
\~ | 上一次替换的字符串 | 没有直接对应，建议显式写出来 |
\%(...\) | 分组但不捕获 | \\(?:...\\) |
举例说明：Vim正则里要匹配一个“没被转义的双引号字符串”，常见的写法是"\zs[^"]*\ze"，用Emacs的正则需要改写成"\\([^"]*\\)"。少了这个转换，经常出现高亮偏移一格的问题。
多语言项目里，还有一类经典踩坑场景是Markdown。Vim里大家习惯用\v魔法模式快速匹配，但同一套正则放到caveman里就需要做完整转义。我的建议是一开始就别让Vim正则习惯延续到caveman规则文件里，全部按Emacs方言来写，免得同一套规则在两种模式下对不上。
5.2 tree-sitter capture映射别硬搬
tree-sitter方案的capture名字在不同语言间并不完全一致。拿最常见的几个来说：
| capture | 语义 | 映射到face |
|---|---|---|
@string | 字符串字面量 | font-lock-string-face |
@comment | 注释 | font-lock-comment-face |
@keyword | 关键字 | font-lock-keyword-face |
@function.call | 函数调用 | font-lock-function-name-face |
@type | 类型名称 | font-lock-type-face |
@constant.builtin | 内建常量 | font-lock-constant-face |
实际迁移的时候，你会遇到大量非标准capture，比如有的语言里泛型参数是@type.parameter，有的语法里函数名是@identifier。这些capture如果不做映射就会被caveman直接丢弃，结果就是那一部分文本没有任何高亮，看起来像是“漏了一块”。
排查办法很简单：打开一个包含目标语法的文件，启用“显示所有未命中字符”的调试机制，caveman会把没有对应规则的token高亮成一种刺眼颜色。看到哪个位置变色，就知道哪个capture没映射上，再回queries文件里找出准确的capture名字补上就行。
这个环节特别能体现caveman的价值：你不需要知道每个tree-sitter grammar内部怎么组织的，只需要维护一张capture映射表。
6. 实测中踩过的三个坑，处理思路一并贴出来
6.1 注释块之后整段变色，歪到文件末尾
现象：某段注释后面的所有代码都染成了注释色，滚动页面的时候高亮范围跟着往下走。
我第一次遇到以为是face配置写错了，清空自定义规则之后问题依旧。后来定位出来是正则规则的问题——定义注释时用了/\*.*\*/，学过正则的都知道.*默认不换行，但如果Emacs的正则引擎在高亮里配置了跨行匹配，这段规则就会从第一个/*一路匹配到最后一个*/，中间无论多少代码都被算作注释。
处理思路也很简单：
- 用更精确的边界，把注释结束符明确写出来；
- 或者限制单行匹配，规则字段里加
:line-limited t； - 再不行就把这条规则从正则方案挪到tree-sitter方案，AST节点天然知道注释的确切范围。
这个坑是“正则方案做注释高亮”里最经典的翻车场景，越早熟悉越省心。
6.2 模板字符串内部${}表达式被染成字符串色
JavaScript里的模板字符串，比如`${name}`，在声明式规则里很容易整段匹配成字符串，内部的动作变量、属性访问也被染成同一个颜色，视觉上分不清哪里是插值。
实际配置中我用的是tree-sitter方案，正常来讲它能识别出${...}内部的表达式节点。但我在project里跑起来之后，插值还是被染成了字符串色，原因是caveman的规则优先级设置——我给了字符串规则很高的优先级，让它优先匹配，结果反过来压制了表达式节点的颜色。
这里最重要的经验是：优先级不是越高越好。priority只应该在确实需要覆盖错误染色时才设置。现在我的做法是让tree-sitter的节点capture保持默认优先级，仅当出现真实冲突时才针对性调高某一条规则的优先级，而不是全局设置一个超大的数字。
6.3 规则一多，输入开始卡顿
配置完一套中等规模语言的规则之后，我发现在大文件里输入字符会有明显延迟，每个字符都要跑一遍全部规则的正则匹配，开销自然大。
处理思路分三层：
- 先将规则的适用范围缩小，正则能限定语言特性的就限定好，比如用锚定、字符类，避免规则在无关区域做无用功；
- 把不必须实时高亮的复杂规则改成延迟计算，caveman支持让某些规则在buffer空闲时才刷新，这样输入时不受影响；
- 如果能用tree-sitter的区域就尽量用tree-sitter，让解析器按AST增量更新，而不是全量重新跑正则。
这三层我目前已跑了一个月，大文件的输入流畅度明显恢复了。实际用下来，我用caveman最大的体会是：别再追求把所有逻辑都塞在声明式规则里，关键区域交给tree-sitter，简单规则用声明式，老配置兜底用正则，三分天下各管一段，才是使用它的正确姿态。如果你的高亮规则也开始越写越多，先停下来做减法，比继续堆规则有用得多。
