从 VS Code 到 Zed：构建 FreeMarker 扩展，因为我需要它
Source: Dev.to
几个月前，我从 VS Code 切换到了 Zed。
并不是因为 VS Code 差——它仍然是一个很棒的编辑器——而是因为它慢慢变得……沉重。我的配置已经变成了一个由免费扩展、后台进程、增值销售以及“再来一个小帮手”组成的弗兰肯斯坦怪物，这不知怎么的让一切变慢了。
我想要一些：
- 快速
- 开源
- 有主见的
- 以最佳方式保持无聊
Zed 满足了所有条件。直到我必须开始使用 FreeMarker。
FreeMarker 仍然活跃
如果你在 Java 或企业环境工作，你已经知道这一点。FreeMarker 并不时髦。它每周都不上 Hacker News。但它 无处不在。
在我的案例中，我在一个集成 Keycloak 的项目中使用它，FreeMarker 模板仍然是定制流程的核心部分。所以是的——FreeMarker 已经很老了。也是的——它仍然至关重要。
这让下面这部分有点 痛苦：
👉 Zed 没有 FreeMarker 支持。
没有语法高亮。
不理解指令。
什么都没有。
“好吧，我自己来”时刻
Zed 足够快，一旦习惯了，再回去使用其他编辑器会感觉…不对。所以我没有再切换编辑器，而是想：
“写一个 FreeMarker 扩展到底有多难？”
（打开 tree‑sitter 语法之前的最后一句话。）
我已经知道 Zed 使用 tree‑sitter：
- 语法高亮基于语法文件
- 扩展简洁且明确
我还有一个起点：一个 FreeMarker extension for VS Code。思路很简单：
- 尽可能复用已有的
- 根据需要进行适配
- 在此过程中学习 Zed 的扩展模型
在 vibe‑coding 的帮助以及大量的反复试验下，我开始移植它。
实际的旅程（又称 tree‑sitter 现实检查）
有些事情比预期更容易：
- Zed 的扩展模型清新简洁
- Tree‑sitter 强迫你正确地思考结构
- 没有魔法，没有隐藏层
有些事情……却不容易：
- FreeMarker 语法以恼人的方式灵活
- 指令、插值、嵌套表达式
- 只有在把一切弄坏后才会注意到的边缘情况
从 VS Code 移植并不是复制粘贴的工作。更像是在两种不同的思维模型之间进行翻译。但说实话？正是这让它变得有趣。
结果：早期，但可用
它目前支持：
- FreeMarker 语法高亮
- 指令
- 插值
- 为进一步改进奠定坚实基础
它完美吗？不是。
它已经达到生产级别了吗？还没有。
它 足够好，能够每天使用而不讨厌你的编辑器 吗？绝对可以。
对于像 Zed 这样的编辑器来说，这已经算是一次胜利。
对 Zed 与小众工具的思考
Zed 给人的感觉像是为以下人群设计的编辑器：
- 喜欢了解工具工作原理
- 更倾向于少一些抽象层
- 不介意自己动手构建缺失的功能
编写这个扩展让我想起了一件重要的事：开源的前进不仅靠大功能——它同样通过那些解决真实问题的小而无聊的小众工具得以成长。FreeMarker 并不酷。但仍然需要有人来维护它。
接下来是什么？
可能的下一步：
- 更好的语法覆盖
- 错误处理
- 未来可能会有 LSP（不保证）
如果你：
- 使用 FreeMarker
- 使用 Zed
- 喜欢玩转开发者工具
反馈、问题和 PR 都非常欢迎。有时最好的扩展源于一个简单的需求：
“我只想让我的编辑器能够理解这个文件。”
而这正是它诞生的方式 🚀