探索 Atomic Editor：为 CodeMirror 6 带来 Obsidian 式的实时预览

追求完美的 Markdown 编辑器往往会面临一个十字路口：文本编辑器的原始、无干扰特性，与 WYSIWYG（所见即所得）界面的即时视觉满足感之间的权衡。对于许多人来说，理想的中间地带是 Obsidian 所推广的“实时预览”范式，即随着用户移动光标，Markdown 语法会被实时隐藏或样式化，从而将纯文本的速度与渲染文档的清晰度结合在一起。

Atomic Editor 作为 CodeMirror 6 的一个专门实现进入了这个领域，旨在为构建其自身文本应用的开发者提供这种流畅的混合编辑体验。通过利用 CodeMirror 6 的可扩展性，Atomic Editor 试图在单一编辑界面内弥合原始源代码与渲染预览之间的差距。

核心主张：CodeMirror 6 中的实时预览

Atomic Editor 的核心设计目标是提供编辑与查看之间的无缝衔接。与传统的拆分窗格编辑器（一侧显示 Markdown，另一侧显示 HTML 渲染）不同，Atomic Editor 会动态修改编辑器的视图。这种方法通过允许作者在不离开源代码文本上下文的情况下查看其格式化后的结构化结果（如表格、复选框和加粗文本），从而减轻了认知负荷。

当前实现中最受赞誉的方面之一是它对复杂 Markdown 元素的处理。用户特别注意到了该工具的“完成度”，并对表格的 WYSIWYG 支持给予了特别称赞，因为表格在实时预览环境中是出了名的难以实现。

技术考量与社区反馈

虽然该项目展示了巨大的潜力，但从原型到生产级工具的转变涉及克服若干技术障碍。来自 Hacker News 开发者社区的反馈突出了几个摩擦点：

状态管理与光标行为

实现实时预览需要对编辑器的状态进行精确控制。一些用户报告在特定元素周围输入时会出现“跳跃”行为，这表明底层文本文档与视觉表示之间的同步偶尔可能会出现不同步或触发意外的布局偏移。

“泄漏的抽象”问题

混合编辑器的主要挑战之一是确保抽象不会“泄漏”——这意味着用户不应被迫以破坏视觉流的方式去处理原始语法。例如，一位用户指出，删除一个起始代码围栏（code fence）可能会导致闭合围栏的行为异常，这表明编辑器处理配对分隔符的逻辑仍需进一步完善。

交互设计

除了渲染之外，编辑器的触感也是讨论的关键点。具体的改进建议包括：

• Selection Highlighting: 用户指出选择高亮显示并不总是如预期般工作。
• Checkbox Ergonomics: 希望复选框在光标靠近时能更直观地转换为可编辑文本。
• Row Deletion: 虽然表格渲染令人印象深刻，但删除表格内特定行的机制仍然是一个摩擦点。

CodeMirror 6 vs. ProseMirror

社区引发了一个有趣的技术辩论，即对于以散文为主的编辑器，选择 CodeMirror 6 而非 ProseMirror。虽然 ProseMirror 是专门为结构化文档和富文本设计的，但 CodeMirror 6 是一个高度可扩展的文本编辑器。选择 CodeMirror 意味着更倾向于维持与底层纯文本文件的强关联，确保编辑器保持“文本编辑器优先”而非“以文本形式保存的文档编辑器”的定位。

结论

Atomic Editor 代表了将一种复杂的编辑范式引入开源生态系统的勇敢尝试。虽然它目前面临着早期项目典型的成长痛——例如光标不稳定性和边缘情况下的语法处理——但它处理表格等复杂元素的能力表明其拥有坚实的基础。对于希望在自己的应用中实现类似 Obsidian 的体验的开发者来说，Atomic Editor 提供了一个了一个引人注目的起点，以及对混合 Markdown 编辑未来的一个窥探。