XI-编辑回顾

四年多前，我开始了Xi-Editor项目。现在我已经把它放在了次要位置(尽管开源社区仍有一些活动)。最初的目标是提供非常高质量的编辑体验。为此，该项目花费了相当多的“新颖点”：以Rust为核心的实现语言。一种用于文本存储的绳状数据结构。多进程体系结构，具有前端和插件，每个插件都有自己的进程。完全采用异步设计。CRDT作为并发修改的机制。我仍然相信有可能在原始设计的基础上建立一个高质量的编辑器。不过，我亦相信这会是一个相当复杂的系统，所需的工作远较所需为多。我已经写了这个回顾的CRDT部分，作为对Github问题的评论。这在黑客新闻上引发了很好的讨论。在这篇文章中，我将再次涉及CRDT，但将重点放在系统设计的其他方面。起源习最初的动机来自于研究Android文本栈，特别是面临两个问题。其一，当文本缓冲区变大时，文本编辑将变得非常慢。第二，EditText小部件和键盘(输入法编辑器)之间的接口中存在许多并发错误。第一个问题的罪魁祸首是span Watcher界面，再加上现代键盘喜欢为每个单词设置拼写更正范围。当您插入一个角色时，所有连续的跨度都会将它们的位置增加一个，然后您必须将每个跨度的onspan Changed发送给所有的观察者。再加上Spans数据结构有一个朴素的O(N)实现，而且整个过程是二次的，甚至更糟。并发错误归结为跨两个不同的进程同步编辑，因为键盘是一个不同的进程，而不是承载EditText小部件的应用程序。因此，当您发送更新(例如，移动光标)而另一侧的文本同时更改时，它是指旧位置还是新位置是不明确的。这是以一种“几乎正确”的方式处理的，有内务更新的超时，以最大限度地减少比赛的机会。这方面的一个很好的表现是，在包含复杂表情的文本中慢慢滑动光标可能会导致表情符号的闪烁。这些问题有一个统一的主线：在这两种情况下，文本都有很小的差异，但数据结构和协议以不太理想的方式处理这些差异，从而导致性能和正确性错误。在很大程度上，习一开始是对处理文本编辑操作的“正确方式”的探索。在并发错误的情况下，我希望找到一种通用的、强大的技术来促进分布式ISH系统中的并发文本编辑。虽然大多数操作转换文献都侧重于多个用户协作编辑文档，但我希望其他文本操作(如在文本输入字段上强制执行信用卡格式的应用程序)也适用于一般框架。那也是我开始沉迷于Rust的时候，所以开始制作一个新的绿地文本编辑引擎的原型是很自然的。如果没有向后兼容性限制(Android中的一个大问题)，您将如何“解析文本”？刚开始的时候，我知道Operational Convert是一种协作编辑解决方案，但以复杂和挑剔著称。我不知道OT和CRDT的兔子洞会有多深。这个故事的大部分都是在之前链接的CRDT讨论中讲述的。模块化软件的诱惑有着极其悠久的历史，人们试图将软件构建为通过某种模块间通信结构连接的可组合模块。历史上的例子包括DCE/RPC、Corba、Bonobo，以及最近的沙尘暴和Fuchsia Modular。有一些部分的成功，包括Android上的Binder，但这在很大程度上仍然是一个未实现的愿景。(关于Binder，它是从一个更理想化的愿景演变而来的，我强烈推荐阅读2006年关于OpenBinder的采访)。当我开始习的时候，有迹象表明我们已经到了那里。微服务在Internet世界变得流行起来，当然，所有Web应用程序都有客户端/服务器边界。在Google内部，GRPC运行得相当好，Chrome内部的进程分离也是如此。在Unix领域，终端本身呈现GUI(如果是原始的，但获得了颜色和鼠标等功能)的历史由来已久。还有Blit的传统，当然，还有新闻和X11。我认为最有力的正面模型之一是数据库/业务逻辑拆分，它可以说是流程分离最成功的示例。在此模型中，数据库是res