mnote/design/05-editor-mainline/reference/5-14-zed-lapce-vscode-reference-adoption-matrix-v1.md

5-14 [reference] Zed / Lapce / VS Code 参考采用矩阵 v1

更新时间：2026-05-19

当前状态：reference。本文是参考实现采用矩阵，不是当前执行 checklist；具体实现任务应拆到对应 domain 的 process/done 文档。

关联背景：

• /mnt/Data1T/mnote/CURRENT_ARCHITECTURE.md
• /mnt/Data1T/mnote/design/05-editor-mainline/reference/5-5-page-aggregate-single-truth-alignment-v1.md
• /mnt/Data1T/mnote/design/05-editor-mainline/done/5-6-page-aggregate-alignment-checklist-v1.md
• /mnt/Data1T/mnote/design/old/07-ai/process/7-14-local-first-ai-markdown-editing-convergence-v1.md
• /mnt/Data1T/mnote/design/04-tree-domain/done/4-24-resource-tree-filetree-pagetree-source-contract-checklist-v1.md

本地参考源码：

• VS Code：/mnt/Data1T/mnote/design/05-editor-mainline/reference-code/vscode
• Zed：/mnt/Data1T/mnote/design/05-editor-mainline/reference-code/zed
• Lapce：/mnt/Data1T/mnote/design/05-editor-mainline/reference-code/lapce
• SideX：/mnt/Data1T/mnote/design/05-editor-mainline/reference-code/sidex-main

1. 文档目的

这份文档回答一个工程路线问题：

MNote 当前 Rust 主线应继续从 VS Code 源码里参考什么，又应该从哪些 Rust 编辑器项目里借鉴现成结构，避免把 VS Code TypeScript / Electron 代码大量转译到 Rust。

当前结论是：

Zed 作为主架构参考，Lapce 作为辅助实现参考，SideX 作为 VS Code 行为迁移到 Rust 后端的桥接参考，VS Code 官方源码作为行为规格参考。

这不是说 MNote 要改造成通用 IDE，也不是要复制 Zed / Lapce 的桌面产品形态。MNote 的主线仍然是：

• tree-first graph kernel
• local-first Markdown workspace
• Rust mnote-web Web shell
• Page Aggregate / File Tree / Resource Tree 投影
• Hermes / Reasonix agent 在授权目录内进行文件编辑

Zed、Lapce、SideX、VS Code 只用于补齐“编辑器工作区基础设施”的成熟参考，尤其是文件树、打开态 buffer、dirty/save、搜索、外部文件变更、agent 文件编辑权限这些层。

---

2. 总体判断

2.1 不建议把 VS Code 源码作为转译目标

VS Code 官方源码仍然是 TypeScript / Electron 架构。它对 MNote 有很强的产品行为参考价值，但不适合作为 Rust 代码转译目标。

主要风险：

• VS Code 的 workbench、service、contribution、lifecycle 与 Electron / DOM / Node 绑定很深。
• 大量接口依赖 TypeScript DI、事件模型、extension host 和 workbench contribution 体系，转到 Rust 后会变成重建一套框架。
• 文件服务、保存冲突、watcher、context key 等模块很有价值，但它们的价值在行为合同和边界划分，不在逐行代码。
• MNote 当前不是通用 IDE，而是 local-first Markdown workspace + agent 编辑器，直接转译会把产品边界拉宽。

因此，VS Code 的定位应固定为：

行为规格参考，不作为 Rust 实现蓝本。

2.2 Zed 是当前最接近 MNote 长期主线的 Rust 参考

Zed 的价值不在 UI 壳，而在这条 Rust 原生编辑器链路：

Worktree / Snapshot -> WorktreeStore -> Project / ProjectPath -> BufferStore / MultiBuffer / Editor -> Search / FileFinder -> AgentTool / ToolPermission

这与 MNote 的长期方向高度重合：

• 多 workspace root / local folder。
• 稳定的 {root + relative path} 文件身份。
• 文件树扫描、ignore、watch 增量更新。
• 打开态 buffer、dirty/save、路径到 buffer 的索引。
• 全文搜索、快速打开。
• agent 文件读写、patch、权限与 allowed roots。

Zed 应作为：

workspace / project / buffer / search / agent 文件编辑权限的主参考。

2.3 Lapce 是轻量实现与边界拆分的辅助参考

Lapce 的价值不在“产品完整度超过 Zed”，而在它更轻、更容易抽取工程模式：

UI -> typed RPC -> proxy -> watcher / search / plugin / terminal -> doc / buffer delta / save

这对 MNote 有两类价值：

• typed command / request / response 如何拆到 proxy / backend 执行层。
• 文档 rev / delta / dirty / save 生命周期如何保持简单。

Lapce 应作为：

typed RPC、proxy 边界、doc delta/save、file explorer state machine、配置和 keymap 的辅助参考。

2.4 SideX 不替代 Zed，但应加入参考矩阵

SideX 的 README 明确写的是：

VSCode's workbench, without Electron.

也就是说，SideX 不是 Rust 原生重写 VS Code。它更接近：

保留 VS Code TypeScript workbench / Monaco / service 模型，把 Electron main process、Node fs、node-pty、sqlite、watcher、search 等系统能力替换为 Tauri + Rust command / crate。

因此 SideX 不能替代 Zed 成为 MNote 的主架构参考，原因是：

• 它仍保留 VS Code 的 TypeScript workbench、DI、service、contrib 体系。
• 它的目标是“移植 VS Code”，不是建立 projection-first 的 local-first Markdown workspace。
• 它会把 MNote 拉回通用 IDE / extension host / desktop shell 的复杂度。

但 SideX 很适合作为一类新参考：

VS Code 行为如何落到 Rust 后端的迁移样本。

它比官方 VS Code 更接近 MNote 的地方在于：

• Rust sidex-workspace 已经抽出 file tree、watcher、search、path util、dirty diff、multi-root 等 workspace crate。
• Rust sidex-keymap 已经实现接近 VS Code when clause 的 context key evaluator。
• Rust sidex-settings 已经实现 default / user / workspace 的分层 settings。
• Tauri command 层把 fs、terminal、git、search、storage 等 Node/Electron 能力转换成 Rust command 边界。

所以本矩阵应把 SideX 放在：

“VS Code 行为规格”和“MNote Rust 实现”之间的桥接参考。

2.5 Helix 不作为主参考

Helix 是优秀的 Rust 终端编辑器，适合参考 LSP、Tree-sitter、文本核心和配置理念，但它不是 workbench / Web shell / local-first workspace 主参考。

---

3. 参考源职责划分

3.1 Zed：主架构参考

重点参考：

• crates/worktree/src/worktree.rs
• crates/project/src/worktree_store.rs
• crates/project/src/project.rs
• crates/project/src/buffer_store.rs
• crates/project/src/project_search.rs
• crates/file_finder/src/file_finder.rs
• crates/agent/src/tools/edit_file_tool.rs
• crates/agent/src/tools/read_file_tool.rs
• crates/agent/src/tools/write_file_tool.rs
• crates/agent/src/tools/edit_session.rs
• crates/agent/src/tool_permissions.rs

不重点采用：

• GPUI / Entity / App / Window 渲染壳。
• pane / dock / desktop lifecycle。
• collab / remote / diagnostics 的完整产品线。
• 与 MNote local-first Markdown 主线无关的通用 IDE 复杂度。

3.2 Lapce：辅助实现参考

重点参考：

• lapce-app/src/doc.rs
• lapce-rpc/src/proxy.rs
• lapce-proxy/src/dispatch.rs
• lapce-proxy/src/watcher.rs
• lapce-app/src/file_explorer/data.rs
• lapce-app/src/global_search.rs
• lapce-app/src/command.rs
• lapce-app/src/main_split.rs
• lapce-core/src/syntax/mod.rs
• lapce-core/src/language.rs
• lapce-core/src/encoding.rs
• lapce-app/src/config.rs
• defaults/settings.toml
• lapce-app/src/keypress/loader.rs
• defaults/keymaps-common.toml
• lapce-proxy/src/plugin/mod.rs

不重点采用：

• Lapce 自身 UI 框架选择。
• 完整插件生态重建。
• 终端、调试器等 MNote 当前阶段不需要的 IDE 面。

3.3 VS Code：行为规格参考

继续参考：

• src/vs/platform/files
• src/vs/platform/commands
• src/vs/platform/contextkey
• src/vs/workbench/contrib/files
• src/vs/workbench/services/filesConfiguration
• src/vs/base/browser/ui/list
• src/vs/base/browser/ui/tree

重点看行为：

• file service 的能力边界。
• save / save as / revert / conflict 的用户体验。
• workspace watcher 与外部文件变更处理。
• context key / command enablement。
• file import / export / open editors。
• tree/list 的选择、焦点、键盘导航和 DnD 行为。

不采用：

• TypeScript service 体系逐行转译。
• Electron workbench lifecycle。
• VS Code extension host 作为 MNote 当前插件模型。

3.4 SideX：VS Code 行为到 Rust 后端的桥接参考

重点参考：

• ARCHITECTURE.md
• src-tauri/src/lib.rs
• src-tauri/src/commands/fs.rs
• src-tauri/src/commands/validation.rs
• crates/sidex-workspace/src/lib.rs
• crates/sidex-workspace/src/file_tree.rs
• crates/sidex-workspace/src/watcher.rs
• crates/sidex-workspace/src/search.rs
• crates/sidex-workspace/src/path_util.rs
• crates/sidex-keymap/src/context.rs
• crates/sidex-keymap/src/resolver.rs
• crates/sidex-settings/src/settings.rs
• crates/sidex-settings/src/jsonc.rs
• crates/sidex-terminal/src/pty.rs
• crates/sidex-terminal/src/manager.rs

重点看边界：

• Electron / Node 能力如何映射为 Rust command。
• 文件系统 command 如何先做 path validation，再进入 workspace crate。
• Rust watcher / search / file tree 如何对外输出可序列化事件和结果。
• VS Code when clause / context key 如何在 Rust 侧建模。
• default / user / workspace settings 如何分层合并。
• PTY / terminal manager 如何从 Node native 模块迁移到 Rust。

不采用：

• VS Code TypeScript workbench 的整体移植路线。
• Tauri desktop shell 作为 MNote 当前 Web 主壳。
• extension host / debugger / terminal / git 的完整 IDE 产品面。
• SideX 当前对绝对路径 command 的简单安全模型；MNote 必须继续使用 allowed roots、workspace root、symlink escape 和文件版本仲裁。

---

4. 采用矩阵

主题	主参考	MNote 当前缺口	采用方式	优先级
ProjectPath / 文件身份	Zed ProjectPath	local folder、page .md、resource asset 需要稳定 {workspace/root + rel path} 身份	借鉴模式，映射到 KernelObjectIdentity / File Tree row	P0
Worktree / root 管理	Zed worktree + worktree_store，SideX sidex-workspace	local-first workspace 需要扫描、ignore、watch、root id、路径归一	Zed 做主模型，SideX 补充 Rust workspace crate 拆分参考	P0
BufferStore / 打开态文件	Zed buffer_store，Lapce doc.rs	tiptap、AI、外部编辑器会同时触碰同一 .md，需要统一 dirty/save/version	Zed 做架构，Lapce 做简化实现参考	P0
dirty / save / external change	VS Code file save 行为，Zed buffer，Lapce doc，SideX dirty diff / watcher	/api/documents/save 兼容面仍未完全退出，文件版本冲突模型待收口	VS Code 校准行为，Zed/Lapce 定模型，SideX 看 Rust watcher / dirty diff 落点	P0
agent 文件编辑权限	Zed edit_file_tool / tool_permissions	Hermes / Reasonix 需要 allowed roots、symlink escape、防脏 buffer 覆盖	直接作为权限模型主参考	P0
workspace search	Zed project_search，Lapce global_search，SideX sidex-workspace/search.rs	MNote 需要本地全文搜索与 Page Aggregate / File Tree 对齐	Zed 做主搜索模型，Lapce 做结果投影，SideX 补充 Rust 并行搜索实现参考	P1
file finder / quick open	Zed file_finder	工作区文件快速打开与 object tab host 尚未成体系	借鉴候选生成与排序，不复制 UI	P1
file explorer 状态机	Lapce file_explorer/data.rs，SideX file_tree.rs，VS Code tree 行为	File Tree / Page Tree / Resource Tree 需要选择、展开、刷新、右键命令一致性	Lapce 状态机 + SideX Rust file tree 能力 + VS Code 行为规格	P1
command / context key	VS Code commands / contextkey，SideX sidex-keymap/context.rs，Lapce command.rs	tree/page/object tab 命令 enablement 仍容易散落到 UI	VS Code 给语义，SideX 给 Rust when-clause evaluator 参考	P1
typed RPC / backend proxy	Lapce lapce-rpc + lapce-proxy，SideX Tauri commands	Rust Web、worker、local FS executor、agent runtime 需要 typed request 边界	Lapce 参考协议拆分，SideX 参考 Node/Electron 能力迁移到 Rust command	P2
config / settings	SideX sidex-settings，Lapce config.rs + settings.toml，VS Code settings 行为	workspace / user / page options / AI policy 需要层级合并规则	SideX 分层 settings 更接近 Rust 落地，Lapce/VS Code 校准行为	P2
keymap	SideX sidex-keymap，Lapce keypress loader，VS Code keybinding 行为	editor shell、file tree、command palette 后续需要统一快捷键	SideX 参考 Rust context/when 解析，Lapce 参考 loader，VS Code 校准行为	P2
terminal / PTY 边界	SideX sidex-terminal，VS Code terminal 行为	MNote 当前不是 IDE 终端优先，但 agent/local workspace 后续可能需要受控命令执行面	只参考 Rust PTY manager 和安全边界，不进入当前主线	P3
MultiBuffer / excerpts	Zed MultiBuffer	AI review、搜索结果、跨文件上下文需要多片段视图	Phase C 之后采用，当前不前置	P3
review diff / streaming apply	Zed agent edit session，VS Code diff 行为	AI suggest/review 仍设计冻结	只保留为后续参考，不当前实施	P3
插件运行时	Lapce plugin，SideX WASM extension，VS Code extension host	MNote 当前插件是 simplemindmap / office / local tool，不需要通用扩展平台	暂不采用，只保留观察	P3

---

5. P0 实施建议

P0 不应从 UI 开始，而应先把文件身份、打开态 buffer 和 agent 文件权限三个底座定住。

5.1 固定 MNote 的 WorkspacePath

目标：

用一个 Rust 侧稳定结构表达“哪个 workspace root 下的哪个相对路径”。

参考：

• Zed ProjectPath
• Zed WorktreeStore

建议语义：

• workspace_id
• root_id
• source_kind
• relative_path
• object_identity
• resource_kind

约束：

• 不允许 UI 只拿绝对路径当对象身份。
• 不允许 Page Tree / File Tree / AI 工具各自生成不同 path key。
• symlink、..、case sensitivity、ignore 规则必须由 Rust workspace 层处理。

5.2 建立 BufferStore / DocumentBuffer 最小模型

目标：

让 tiptap autosave、AI 文件写入、外部编辑器修改都围绕同一份文件版本和 dirty 状态仲裁。

参考：

• Zed buffer_store.rs
• Lapce doc.rs
• VS Code save conflict 行为

建议最小字段：

• workspace_path
• file_version
• base_content_hash
• current_content_hash
• dirty_state
• last_loaded_at
• last_saved_at
• external_change_state

当前必须避免：

• 继续把 /api/documents/save 当长期正文写入主入口。
• tiptap 和 AI 分别维护互不知情的 revision。
• 外部文件变更直接覆盖前台 dirty buffer。

5.3 收口 agent 文件编辑权限

目标：

MNote 只负责计算授权范围和同步投影，Hermes / Reasonix 在 allowed roots 内用自身 patch/diff 能力编辑文件。

参考：

• Zed edit_file_tool.rs
• Zed edit_session.rs
• Zed tool_permissions.rs

必须具备：

• allowed roots。
• 当前文件引用。
• selection / range。
• symlink escape 防护。
• dirty buffer 写入前检查。
• 写后 watcher / projection refresh。

这条线与当前 7-14 online/local AI Markdown editing convergence 一致：普通 local-first Markdown 编辑优先走 agent 原生文件编辑能力，mnote.doc.markdown_edit 只作为 cloud / remote agent / compat fallback。

---

6. P1 / P2 / P3 实施建议

6.1 P1：搜索、文件树、命令上下文

P1 解决的是 workspace 产品体验闭环：

• 本地全文搜索。
• 快速打开。
• File Tree / Resource Tree / Page Tree 展开、选择、刷新、右键命令。
• command enablement / context key。

参考组合：

• Zed project_search + file_finder
• Lapce global_search + file_explorer/data.rs
• VS Code tree/list/contextkey 行为

验收口径：

• 搜索结果能回到稳定 WorkspacePath / ObjectIdentity。
• 文件树操作只发 command，不直接改真实对象。
• 右键菜单和快捷键基于统一 command context，不在 UI 分支里临时判断。

6.2 P2：typed RPC、配置、keymap

P2 解决的是边界清晰和长期可维护：

• UI 到 Rust executor 的 typed request / response。
• user / workspace / page / runtime policy 的配置合并。
• 编辑器、树、command palette 的 keymap 加载和冲突处理。

参考组合：

• Lapce lapce-rpc/src/proxy.rs
• Lapce lapce-proxy/src/dispatch.rs
• Lapce config.rs
• Lapce keypress/loader.rs
• VS Code settings / keybinding 行为

验收口径：

• route / compat / worker 不再各自定义一套命令 payload。
• 配置合并顺序可解释、可测试。
• 快捷键归属到 command，不直接绑定到某个 DOM 事件分支。

6.3 P3：MultiBuffer、review diff、插件运行时

P3 只作为后续能力，不进入当前最前排。

可参考：

• Zed MultiBuffer：搜索结果、AI 上下文、多文件 excerpt。
• Zed agent edit session：review / apply / reject。
• VS Code diff：冲突、review、保存体验。
• Lapce plugin：轻量插件隔离。

当前边界：

• 不实施流式 apply + suggest/review。
• 不重建 VS Code extension host。
• 不把 MNote 拉成通用 IDE。

6.4 SideX 专项采用边界

SideX 可以补强 P1 / P2，但不改变 P0 主线。

可以参考的部分：

• sidex-workspace 的 crate 拆分：file_tree / watcher / search / path_util / dirty_diff / multi_root。
• src-tauri/src/commands/fs.rs 的 command facade：前端请求先进入窄 command，再进入 Rust workspace 能力。
• src-tauri/src/commands/validation.rs 的输入校验意识，但 MNote 需要更强的 workspace root / allowed roots / symlink escape 校验。
• sidex-keymap/context.rs 的 when clause AST 和 evaluator，可作为 MNote command context 的 Rust 参考。
• sidex-settings/settings.rs 的 default / user / workspace settings 分层，可作为 MNote user / workspace / page / AI policy 合并规则的早期参考。
• sidex-workspace/search.rs 的 ignore-aware、rayon 并行全文搜索，可作为本地 Markdown workspace 搜索实现参考。

不应采用的部分：

• 不采用“把 VS Code TypeScript workbench 原样移植到 Tauri”的产品路线。
• 不把 MNote 3000 Rust Web 主壳替换成 Tauri desktop shell。
• 不把 extension host / debugger / terminal / git 做成当前默认产品能力。
• 不直接沿用 SideX 的绝对路径 command 安全模型；MNote 必须以 workspace identity、allowed roots、file version 和 agent permission 为准。

对 MNote 的实际帮助是：

当我们从 VS Code 学到一个行为时，可以先看 SideX 是否已有 Rust crate / Tauri command 级别的落地方式；如果有，就用 SideX 校准“这个行为如何从 Node/Electron 能力迁移到 Rust 后端”，再按 MNote 的 kernel / projection / command contract 重写。

---

7. VS Code 仍应继续看的源码

虽然不建议转译 VS Code，但下面这些仍值得继续深读，因为它们定义了成熟编辑器的行为边界。

7.1 文件服务与保存冲突

重点：

• src/vs/platform/files
• src/vs/workbench/services/filesConfiguration
• textFileSaveErrorHandler

关注问题：

• 文件不存在、权限失败、外部修改、编码变化、只读文件如何呈现。
• dirty buffer 与磁盘版本冲突时如何让用户选择。
• save / save as / revert 的命令边界。

7.2 Watcher 与外部变更

重点：

• workspaceWatcher
• file service event。

关注问题：

• 外部编辑器修改 .md 后如何刷新投影。
• 当前 buffer dirty 时如何避免静默覆盖。
• rename / delete / move 对打开 tab 和 file tree 的影响。

7.3 Context Key 与 Command Enablement

重点：

• src/vs/platform/contextkey
• src/vs/platform/commands

关注问题：

• 命令是否可用不应散落在 UI 条件判断里。
• File Tree / Page Tree / Object Tab / Editor selection 应贡献统一 context。
• 右键菜单、快捷键、command palette 应消费同一套 command context。

7.4 Tree / List 行为

重点：

• src/vs/base/browser/ui/list
• src/vs/base/browser/ui/tree
• src/vs/workbench/contrib/files

关注问题：

• 展开、收起、选择、焦点、键盘导航。
• DnD 和 rename 的边界。
• open editors / file explorer 如何处理打开态与磁盘态。

---

8. 风险与边界

8.1 许可与代码来源边界

Zed、Lapce、VS Code 都只能作为参考来源。后续实现应遵循：

• 不直接复制大段源码。
• 不把第三方项目的 UI 壳、生命周期和产品概念搬进 MNote。
• 引用具体设计时在设计稿或实现注释中标明“参考模式”，避免伪装成原创推导。

8.2 产品边界风险

MNote 不应因为参考 Zed / Lapce / VS Code 而变成通用 IDE。

必须保持：

• 页面正文真相仍是 local-first .md。
• Rust kernel 持有树、资源、投影、命令语义。
• Page Aggregate 是页面主投影。
• File Tree 是 local workspace 的组织投影。
• Hermes / Reasonix agent 文件编辑必须受 allowed roots 和文件版本模型约束。

8.3 技术路线风险

最大风险不是“参考不够”，而是参考源混用后边界变模糊。

固定规则：

• Zed 负责主架构参考。
• Lapce 负责轻量实现参考。
• SideX 负责 VS Code 行为到 Rust 后端的迁移参考。
• VS Code 负责行为规格参考。
• MNote 自己的 Rust kernel / projection / command contract 负责最终真相。

---

9. 当前建议结论

后续推进顺序建议固定为：

1. P0：WorkspacePath / ProjectPath、WorktreeStore、BufferStore、agent file edit permission。
2. P1：workspace search、file finder、file explorer state machine、command context。
3. P2：typed RPC / proxy、SideX-style Rust command facade、config、keymap。
4. P3：terminal / PTY 边界、MultiBuffer excerpt、review diff、插件运行时。

一句话结论：

不要把 VS Code TypeScript 源码转译成 Rust；应以 Zed 的 Rust workspace / buffer / agent 架构为主参考，以 Lapce 的 typed RPC / proxy / doc delta 为辅助参考，以 SideX 校准 VS Code 行为迁移到 Rust 后端的落地方式，再用官方 VS Code 校准成熟编辑器行为。