当 DSH 适配了 Quirekit md-editor: 你的笔记软件为何不能是 DSH（MIT开源）
声明：本文未使用任何 AI 进行任何一行的优化。也未参考 AI 输出，全文手动编辑码字。
最近生病身体不是很舒服，没有仔细琢磨文章，由于也没有库存文章来发布，所以除了看病，休息，我更多还是在完善 quirekit 的体系，并且顺便做了点小东西，那就是 dsh-quirekit-md-editor。
先说说是什么
我日常主力生产工具还是 codex、claude code，但 dsh 会作为我经常会用的备用方案来进行一些简单任务的执行。不过在使用 dsh 的过程中，我发现它跟 codex 这些主力产品的一个很大的差异点是它打开的 markdown、代码都只是预览版的。
在这个背景下，结合我们 md-editor 产品的发布，我决定为 dsh 适配一套超好用的内置 md 编辑器 dsh-quirekit-md-editor，其实这也符合我一直的想法：编辑器、笔记产品的赛道很卷，我不想做芸芸众生中的同质化产品，也不想跟 AI 趋势对抗，我想做的是融入各种产品，例如其他笔记产品、Agent 产品，或者各种公司定制化的编辑器，反正就是融入而非对抗。
先看集成效果：
凭什么是 dsh-quirekit-md-editor?
说实话，并不是我一个人注意到了 dsh 无法编辑 md，我看到社区也存在 Marktext，Better Sidebar 等产品，但为什么我还要做，以及做完后凭什么让大家选择我，而不是其他？这对于 quirekit 的 md-editor 来说，并不算是什么困扰，因为我们本身就有很多目前其他方案给不了的东西，这些差异化就是让别人选择我们的理由。
1. 独特的多模式编辑
市面上大多数编辑器，要么提供类似 vscode md-editor 一样的半富文本编辑器状态，要么提供左输入右预览的形态，还有人提供 tiptap 负责富文本，codemirror 负责源码模式的重型形态（存在 pm json 转换，md 源码一定会被格式化）。
但我一直在想，为什么编辑器必须是左右结构？或者富文本模式为什么必须是 tiptap 这种富文本编辑器实现？因此我们基于 codemirror 设计了一套 tiptap api style 的 msfe（markdown 源码优先的编辑器框架）。在这套模式下，我们实现了纯源码编辑、半源码半富文本编辑（选中目标会展示为 md 源码格式）、以及全富文本模式（隐藏 md 围栏与标记，体验与 飞书文档、notion 类似，但实际的修改永远都是 md 字符串）。
在这种体系下，所有模式的菜单、操作等各个模式都是共享的，例如评论：
格式设置等操作源码模式照样有完善的体验:
这种体验，我几乎没在市面上的其他编辑器中体验过。
2. 惊人的性能
quirekit 的 codemirror 是拉了源码使用 vendor 版本的，这就给了我们很多机会去改造源码。
改造最大的是 lezer 的算法，lezer 本身其实也是增量的，改完一个字，它只重新解析改动附近的几块，其余的块直接从上一次的语法树里拿过来用。但问题是它拿的时候是一块一块拿的，如果改动点后面有一千个段落，就要逐个检查、逐个接回新树，文档越长，每敲一个字要做的事就越多。
Lezer 自身有个优化：它为了让编辑器按位置查找节点更快，在建对象树的时候，会自动把相邻的块打包成组，组再打包成更大的组，只是复用旧树时没有用上这层结构。
我们的优化策略是：如果整组都没变，那就一次把整组接回来，不再逐块处理，只有组是个复杂结构，例如代码或者列表，才按原来的方式逐块判断，因为在 markdown 中，这些内容本身就是一个整体，对 md 的拆分如果不正确就会造成一些结构的变化。改完后，300 万字的文档和 10 万字的文档，敲一个字的解析开销基本一样。
以下是之前做的一个优化对比：
| 工作量 | 优化前 | 优化后 |
|---|---|---|
| 语法树访问 | 107,760 | 1,380（少了 98.7%） |
| 语法树比较 | 153,940 | 660（少了 99.6%） |
不过为了保证正确性，对于例如超大的列表，可能还是会在列表这一部分的修改上回退到原来的 lezer 逻辑，不过也就只是这一小块，这个优化我也提取成了新版的 incremark。在此之前，我还开源过一个不太成熟的方案，基于断行实现的 increamrk，处理过程中就遇到了很多拆分导致的坑。
在 dsh 插件实现过程中，我顺便还优化了一下 UI 层更新导致的性能开销，对比已有的 Marktext，Better Sidebar 产品，也让 claude 做了实测性能比较：
因此我们的编辑体验对于大文档非常有优势，不会因为文件变大导致性能变差，编辑非常跟手。
https://markdown.quirekit.com/#algorithms 这里我放了一个动画，可以可视化地演示我们的更新策略
3. 丰富的交互功能
我们的 md-editor 本身就设计了各种各样复杂的块，自研的公式编辑器，并且内置多种图形编辑方案，包含：
- 三种文本绘图方案：mermaid、plantUML、Graphviz
- 自研流程图组件与文本化存储方案
- 自研思维导图组件与文本化存储方案
- Excalidraw 白板组件与文本化存储方案
我们为了 dsh 原生能生成图文并茂且好看的文档，内置了相关 skill 说明，dsh 可以原生生成图文并茂文档。
4. 深度交互集成上的创新
对于 md-editor 我们提供了选中文本后发送给 dsh 的能力，这是其他产品也拥有的：
同时，我们的 md-editor 本身具备评论功能，基于这一点，上面的滑词发送其实就显得有点线性、单条了，我们可以依据评论功能，实现批量操作，我们对不满意的地方，可以选中进行评论，整体优化方案后，再让将评论整体发送给 dsh，直接批量处理。
当然评论本身也具备单条发送的能力：
安装方法：
需要 DSH 0.2.2-rc.1 及以上（低版本没测过），Web 版执行：
▼bash复制代码dsh plugin --profile web add dsh-quirekit-md-editor
重启 dsh web，再从“文件”标签打开 Markdown 文件就行。桌面版在“插件”页点“添加插件”，输入 dsh-quirekit-md-editor 安装并启用。完整的演示视频在 GitHub 仓库的 README 里。
- GitHub：https://github.com/quirekit/dsh-quirekit-md-editor
- 编辑器在线试用：https://msfe.quirekit.com/md-editor/
这个插件里的编辑器就是 QuireKit 生态中的 MD Editor，想放进自己的产品可以直接 npm install @quirekit/md-editor。DSH 插件是我拿它做的一个外部集成，用起来有什么问题，欢迎在 GitHub 提 issue，或者直接在下方留言。
本文首发并持续更新于 yishuai.wang。
