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 测试人员社区。
我们大多数人都听过这样的建议：“如果你在启动时感觉一切都准备就绪了，那就说明你等得太久了。” 我同意这一点，但我们也要确保在发布公开 Beta 版本之前，我们能够给任何尝试 Zed 的人留下积极的印象。根据我们 Alpha 社区的反馈，我们认为我们已经接近了。
上周，我们进行了第一次质量周，我们放下手头的一切工作，专注于修复尽可能多的小错误和摩擦点。我们计划每六周重复一次，以确保我们修复所有可能破坏一款原本很棒的产品的细微之处。下周的发布将包括这项工作的成果，在这些更改在我们的内部预览版本上稳定下来之后，Zed 应该会感觉更加完善。
我们很高兴分享的一件事是多缓冲区性能的大幅提升，尤其是在项目范围搜索的上下文中。以前，在存在大量摘录的情况下，主线程会被阻塞，因此上周 Antonio 深入研究以找出原因。
为了检测对摘录的更改，我们在我们的绳索数据结构中维护一个指纹。我有一篇关于 Zed 中绳索的未完成的博客文章，但简而言之，我们会在 B 树中索引文本块。索引数据包括一个指纹，以帮助我们廉价地确定缓冲区是否与文件系统的内容匹配。我们使用 bromberg_sl2 crate，它提供了一个提供幺半群同态的哈希函数。来自 README
这意味着存在一个廉价的操作 _，使得给定字符串 s1 和 s2，H(s1 ++ s2) = H(s1) _ H(s2)。
这允许我们通过 B 树向上聚合绳索内容的摘要。为了跟踪缓冲区的干净/脏状态，我们将这些指纹保存为 String。对于通常占据工作区的缓冲区数量来说，这很好，但是当同步具有大量摘录的多缓冲区时，相关的分配会导致性能问题。我们切换到直接使用 bromberg_sl2 的 HashMatrix 类型，这需要对 crate 进行一些修改，并立即获得了收益。
我们还发现，将大量摘录推送到多缓冲区会阻塞主线程，因此我们现在在后台线程中构建摘录，并以异步方式将它们流式传输到多缓冲区中。因此，当我们在增量加载结果时运行大型搜索时，Zed 仍然保持响应。
这只是上周发布的众多改进之一。查看未来两个版本中的发行说明，了解更多关于我们修复的所有内容。我们希望它可以改善您的生活质量。
本周，我们将重新投入到各种任务中，这些任务将使我们更接近发布公开 Beta 版本。特别感兴趣的是性能遥测。我们想知道 Zed 的表现如何，以便我们可以修复任何问题，并在添加功能时保持我们的高性能标准。
感谢您的阅读。我很高兴开始为那些感兴趣的人分享更多关于 Zed 的详细信息。