从打开一个文件，到打开一个项目

前几篇把文本内核、终端闭环和中文输入讲完了。到了 M3，砚要解决一个更贴近日常使用的问题：我通常打开的是一个项目，接着在一堆文件之间来回找。

这时编辑器的体验，开始由"找到文件有多顺手"决定。

资源管理器适合按目录逐层展开；快速打开需要拿到整个项目的候选路径。如果让文件树一开始就递归生成所有节点，启动会背上不必要的工作。

所以砚把它们拆开：目录树按需展开，文件索引在后台通过 fastwalk 遍历。索引结果分批交回内核，快速打开也不用等全项目扫描完成后才出现。

索引有 20 万文件的上限，避免把无边界的目录遍历直接变成内存账单。只打开一个不在 Git 项目里的普通文件时，也不会顺手把它的上级目录当成项目扫描。否则打开家目录里的一个笔记，可能连带开始索引完全不相关的东西。

忽略规则有目录作用域，有嵌套，还有 ! 反向规则。把全项目的规则揉成一个列表，既可能改变语义，也会让每个路径匹配太多无关模式。

砚按 .gitignore 所在目录组织规则，再沿相关层级匹配。资源管理器里，部分忽略项变暗；.git、node_modules 这类目录隐藏。给人浏览的树和提供搜索候选的索引，也不必照着同一套展示策略输出。

这段开发很适合学习文件系统工具：优化之前先看规则作用域和遍历成本。某个大目录慢，不一定是模糊匹配慢，也可能时间都花在系统读取目录上。

砚的快速打开支持路径模糊匹配、最近文件、:行号 跳转和 > 切命令面板，也兼容中文输入下的全角 ：、》。

这些功能看着小，但输入过程中最容易暴露异步状态问题。

比如依次输入 a、ap、app，三个查询的完成顺序未必一致。旧查询就算晚一步完成，也不能覆盖最新输入的结果。砚把匹配放在后台，输入变化时取消旧任务，回传时还要确认任务仍然有效。

后面做项目搜索时，同样的问题会再出现，而且从"列表显示错"升级成"可能替换错文件"。这时积累的任务生命周期约定就派上用场了。

打开、切换、关闭标签，背后对应着文档、选区、滚动位置和未保存内容。

M3 已经有多标签与脏文件关闭确认；后续又增加了单击预览、双击固定、重新打开关闭的标签和分栏。预览标签一旦真正编辑，就不能再被另一个单击轻易替换。

在功能表里，这些可能只是几个勾；在使用中，它们决定了"我刚才的东西去哪了"。所以命令和焦点模型必须一起做：当键盘在文件树里，方向键控制目录；浮层打开后，输入优先进入浮层。

最初配置按内置默认值、用户 config.toml、项目 .yan.toml 叠加。后来菜单选择的主题、字号等和会话写进 state.json，这部分状态也会影响最终设置。

这里要区分两种"立即生效"：当前在砚里保存配置会触发重读，但不代表所有外部修改都有文件监听来自动重载。旧 M3 阶段也还没有后来的配置重读和预览标签能力。

磁盘上的文件可能被 shell、格式化工具或另一个编辑器改掉。切回窗口或从 shell 返回后，要检查：干净文档可以重载，有本地未保存修改则不能直接覆盖。

M3 完成以后，砚终于从"打开一段文字"变成了"在项目里走动"。下一次大的变化，来自另一个 Go 编辑器：Mayoi。