路线拐了个弯：接入 MyGo，借鉴 Mayoi

如果只看砚最初的设计文档，会以为它应该一直沿着"终端 → Gio → LSP 和 Git"往前走。

实际开发在 M3 后拐了个弯：看到 Mayoi 之后，窗口前端改用 MyGo，同时借鉴和移植了 Mayoi 的一批编辑器能力。窗口和 Git 都比原计划更早进入了项目。

这一篇记录的重点，就是这次转向究竟换了什么，又保留了什么。

砚已经有文本快照、多选区、撤销、工作区和终端前端。决定接入 MyGo 时，这些仍然继续使用。

MyGo 负责窗口层，编辑行为依然经过 core/app。前端得到 Frame，发回点击标签、选择文件、修改搜索条件等动作。文本真值没有再交给一个独立的 GUI 编辑框维护。

这也是前面坚持无头内核的一次实际收益。换窗口技术，不必把文件保存、撤销和选区也重新搬家。

从仓库记录看，窗口层先锁定 MyGo 0.4.1，后来升级到 0.4.8，再为终端能力使用一个固定提交的 fork。版本演进都有具体原因，最后一段会在终端那篇展开。

Mayoi 的一些能力可以按包移植，例如高亮、符号提取、Git CLI 封装、行 diff、搜索 glob。砚保留来源声明和测试，再处理必要适配。

另一些功能则需要在砚的状态模型里重写：行编辑、自动闭合、查找替换、Vim 模式、分栏、预览标签、粘性作用域、面包屑、主题与会话恢复。

这里最容易踩的坑是坐标。来源项目的某个"列号"，不能默认就等于砚的 UTF-8 字节偏移。另一个坑是状态所有权：原来直接操纵窗口组件的代码，放进砚以后必须回到共享内核。

对照表因此非常有用：每一项写清楚来源、落到哪个包、终端与窗口分别支持到哪。它比一句"功能基本都搬过来了"更容易维护。

最初的高亮计划是自己写行状态词法器，优先覆盖几种常用语言。接入 Mayoi 后，采用了基于 Chroma 的高亮实现。

这样更快获得了广泛的语言覆盖、可视区高亮和括号着色，也少维护一批语法规则。代价则很直接：终端二进制变大。

ADR 当时记录，终端构建从约 3.6 MB 增长到约 8.4 MB，门禁由 6 MB 调到 10 MiB。数字属于当时的构建，今天写这篇没有重新测量。

对我来说，这个决定的关键在于接受具体交换：用一些体积换语言覆盖和开发时间。后续如果重新强调极小体积，可以再讨论按构建标签裁剪；但那仍然是回退方案，当前并没有这么拆。

砚的常规构建使用 CGO_ENABLED=0，MyGo 经 purego 调用系统能力。但窗口里的内嵌终端仍然使用 libghostty-vt。

所以产品打包时，除了 Go 可执行文件，还要考虑运行时动态库、资源和对应声明。开发环境能自动取得库，也不能推出发给别人时可以漏掉它。

同样，MyGo 提供窗口和输入法接口，也不代表砚的中文输入流程自然通过验收。框架能力接进应用后，还要验证组字目标、选区替换、焦点和撤销。

这阶段进入砚的能力很多：自动闭合、缩进参考线、同词与括号高亮、行注释、移动和复制行、Vim 模式、主题、字号、图片与 SVG 查看、预览标签和分栏。

它们共同改变了使用方式：砚开始能承接一小段完整的阅读和修改工作，而不只是打开文件看看。

与此同时，最初的非目标也发生了变化。面包屑、粘性滚动、Vim 和更完整的 Git 界面，原来都曾放在范围外。现在要把这些变化写进 ADR，而不是让旧文档继续假装路线从没变过。

下一篇会讲这次扩展最需要警惕的一面：功能越丰富，能写错文件的入口也越多。