Zed 构想的最初源头是一个名为 Xray 的实验性编辑器项目，我和我的联合创始人 Antonio 在2018年上半年致力于这个项目。为了确保管理者能了解我们的工作，我在 xray 仓库中每周更新日志，记录我们的进展。不久，Atom 社区的成员发现了它，这个日志逐渐演变成一个低调的博客，尽管我不确定是否有任何管理者真正阅读过它。
四年后，我想重新开始这个习惯，为 Zed 发布更频繁的更新。这些更新不会像我们的第一篇博客文章那样精心制作，但似乎一些 Zed 用户会很高兴听到更多关于项目进展的细节。除了这些更频繁的更新之外，我们还将继续发布带有图表等内容的更长篇幅的文章。
自上次 Xray 更新以来的四年里发生的一切，要一一详述是不可能的，但对于那些当时关注我们的人，我将尝试总结一下……
在 GitHub 管理层明确表示 Xray 在公司没有发展前景后，我的第二个女儿出生了，我休息了一段时间。2019年我重新开始工作时，Antonio 和我决定在业余时间继续 Xray 的工作。我们从一个空的仓库重新开始，到2019年秋季，Zed 和 GPUI 的基础开始形成。
2020年，我利用所有空闲时间推进项目，但在那年年底，我收到了 Warp 的工作邀请。我需要改变，所以我决定加入他们，并把我一直在开发的代码带了过去。但三个月后，我意识到我无法放弃构建终极编辑器的梦想，所以我离开了 Warp，创办了 Zed。
Max 和 Antonio 很快加入了我的行列，接下来的几年我们致力于构建在 Zed 中全职编码所需的基本功能。2022年3月，我们完成了转换，从那时起我们一直在稳步改进 Zed，逐步扩大我们的私有 alpha 测试社区。
我们大多数人都听过这样的建议：“如果你在发布时觉得万事俱备，那你就等得太久了。”我同意这一点，但我们也希望确保在公开测试版发布之前，给任何尝试 Zed 的人留下积极的印象。根据我们 alpha 社区的反馈，我们认为我们正在接近目标。
上周，我们进行了第一次“质量周”，我们放下所有工作，专注于修复尽可能多的小 bug 和摩擦点。我们计划每六周重复一次，以确保我们修复所有可能毁掉一个优秀产品的小问题。下周的发布将包含这项工作的结果，这些更改在我们的内部预览版本上稳定后，Zed 应该会感觉更加完善。
我们很高兴分享的一项重大改进是多缓冲器性能的提升，尤其是在项目范围搜索的背景下。以前，在处理大量摘录时，主线程有时会阻塞，所以上周 Antonio 深入研究了原因。
为了检测摘录的变化，我们在绳索数据结构中维护一个指纹。我有一篇关于 Zed 中绳索的博客文章写了一半，但简单来说，我们以 B 树的形式索引文本块。索引数据包含一个指纹，以帮助我们廉价地确定缓冲区何时与文件系统内容匹配。我们使用 bromberg_sl2 crate，它提供了一个提供幺半群同态的哈希函数。摘自 README：
这意味着有一个廉价的操作 _，使得给定字符串 s1 和 s2，H(s1 ++ s2) = H(s1) _ H(s2)。
这使我们能够将绳索内容的摘要向上聚合到 B 树中。为了跟踪缓冲区的干净/脏状态，我们曾将这些指纹保存为 String。这对于通常占据工作区数量的缓冲区来说没有问题，但当同步带有大量摘录的多缓冲区时，相关的分配导致了性能问题。我们转而直接使用 bromberg_sl2 的 HashMatrix 类型，这需要对 crate 进行一些修改，并立即带来了收益。
我们还发现，将大量摘录推送到多缓冲区会阻塞主线程，所以我们现在在后台线程中构建摘录，并将其异步流式传输到多缓冲区。因此，当运行大型搜索并增量加载结果时，Zed 仍然保持响应。
这只是上周众多改进中的一项。请查看接下来的两次发布说明，了解我们修复的所有内容。我们希望它能改善您的使用体验。
本周，我们将重新投入到各项任务中，这将使我们更接近发布公共测试版。特别值得关注的是性能遥测。我们想了解 Zed 的性能表现，以便我们能够修复任何问题，并在添加功能时保持我们的高性能标准。
感谢阅读。我很高兴能开始与那些感兴趣的人分享更多关于 Zed 的细节。