这是 Zed 忙碌的又一周。我们的搜索功能正在获得一项重要的的新功能，WebAssembly 扩展也在逐渐起步，并且我们即将发布新的协作频道功能。
Kyle
本周主要集中精力改造搜索 UI，以整合我们一直在开发的新的语义搜索功能。Piotr 和我已经将 UI 调整到感觉非常流畅直观的状态，我们希望它能比之前的 UI 有所改进。除此之外，还有一些小部分探索，侧重于 Zed 的人工智能未来发展方向，以及扩展我们的检索引擎以纳入重新排序模型。
Piotr
本周我和 Kyle 一起改进了搜索 UI。它很可能会成为下周预览版的一部分。在接下来的一周里，我计划将 UI 更改应用于缓冲区搜索。
Joseph
本周，我制作了一些图表，显示了停止使用 Zed 的用户最常打开哪些文件类型，以尝试获取更多关于人们在 Zed 中尝试使用哪些语言的数据点。我和 Julia 一起头脑风暴了一些可以构建的额外图表，这将有助于更好地了解我们流失的用户正在寻找什么。除了社区工作和一些图表绘制之外，我还向 Zed 提交了一些小的 PR；其中一个向编辑器添加了convert to {upper,lower} case命令（感谢 Julia 的协助）。下周，我计划继续为流失的用户构建图表，我可能会探索构建一个本地工具来聚合用户反馈。
Nathan & Antonio
Antonio 和我本周最感兴趣的事情是两个 CRDB 存储库之间的同步。我们的初始版本依赖于交换向量时间戳，其中包含每个副本 ID 的单调递增计数器。我们使用它来快速确定客户端从服务器端丢失了哪些操作，反之亦然。知道这些时间戳会随着每个副本 ID 的增长而增长，这种方法意味着我们需要集中分配副本 ID，并且还需要在给定的副本上维护状态以跟踪其 ID，这会带来运营复杂性的成本。
因此，我们决定在理论层面上投入更多，并找到一种不依赖于向量时间戳的同步策略。最终，存储库的状态来自一组按 Lamport 时间戳排序的操作，因此新操作倾向于聚集在操作历史记录的右侧。
在探索了几种不同的方法后，我们正在得出一个解决方案，该解决方案涉及确定客户端和服务器之间操作序列的共享前缀的长度。我们使用 Bromberg 关联哈希函数以及我们的通用 B 树数据结构，以 O(log(n)) 时间计算任何操作范围的摘要。当客户端启动同步时，他们会发送涵盖多个范围的摘要。从客户端发送的范围最大的范围开始，服务器会查看连续较小的范围，直到找到匹配的摘要。这是共同的前缀。匹配范围和下一个匹配范围之间的大小差异决定了我们潜在的超调... 共同的前缀可能更大，但我们没有足够的分辨率来知道。
如果潜在的误差小于我们的最大值，我们可以只发送共享前缀之后的所有操作。有些操作已经在客户端上了，但这没关系。如果潜在的误差超过了我们的最大值，我们可以执行额外的往返来优化答案。这一切都是为了在往返的延迟和发送冗余操作的成本之间取得平衡。
我还致力于在 UI 布局 GPUI 中表达 UI 布局，并且它真的开始融合在一起。这是我正在处理的测试的摘录
fn test_layout(cx: &mut TestAppContext) {
let window = cx.add_window(|_| {
view(|_| {
let theme = rose_pine::dawn();
column()
.width(auto())
.height(auto())
.justify(1.)
.child(
row()
.width(auto())
.height(rems(10.))
.fill(theme.foam)
.justify(1.)
.child(row().width(rems(10.)).height(auto()).fill(theme.gold)),
)
.child(row())
});
});
// ...
}很多框架都使用宏 DSL，但我认为存在复杂性权衡。我真的很喜欢用纯 Rust 表达 UI 的想法，到目前为止，我认为这种函数链接方法是合理的。
Max
本周，Mikayla 和我继续致力于 Zed 频道，Zed 频道是用于构建协作的新功能。我们现在有一个用于管理频道和成员资格的 UI，它在很大程度上已经完成了功能，但是很丑陋。下周，我们将完成对其的样式设置，并有望将其发布到预览频道。
Mikayla
本周，我们构建了频道功能的所有核心 UI 和交互！我和 Max 在开发此功能时玩得很开心，我们很高兴看到它如此迅速地成型。随着我们越来越接近内部 MVP，我想谈谈我们如何以及为什么构建此功能。
从根本上讲，频道是人们组织他们在何处以及做什么的方式。就像我们的实际工作一样，频道可以分层组织成一个粗略的主题选择，我们想象会是这样的
- #zed
- #livestreaming
- #public-channels
- #channels-core
- #search-and-replace
- #design
- #wasm
单击任何这些频道会立即启动 Zed 通话，并将您在频道中的状态广播给加入的其他人。有点像 Slack 的即时频道，但具有更多的结构，没有文字聊天（目前）。
但是我们的工作并非纯粹分层，它不能总是干净地分离成各个主题，而且我们经常与其他团队和项目合作。为了适应这种情况，我们将频道数据结构建模为 DAG（有向无环图），允许您以任何有意义的方式将事物链接在一起。例如，我们使用 LiveKit 来支持我们的麦克风和屏幕共享，因此您可以想象我们的两个组织之间有一个共享频道
#zed
- > #livestreaming
- #search-and-replace
- #design
- #livekit 🔗
- #screen-sharing
- #web-rtc
或者您可以为特定功能设置横向关注点
#zed
- > #livestreaming
- #search-and-replace
- #replace-design
- #design
- #replace-design
- > #livekit
或者您可以将您的频道组织成团队和项目
- #crdb-industries
- #design
- #alpha
- #lamport-timestamps
- #branches
- #repository-synchronization
- #november
- #gpui-layout
- #branches
- #repository-synchronization
仍然觉得树结构太严格？创建另一个频道并以您想要的任何方式组织它们！
- #my-freelance-design-business
- > #crdb-industries/#design
- > #zed/#design
这种灵活性的动力是频道具有两个基本属性：任何频道的权限都会向下级联到所有子频道，并具有减法干扰，并且如果没有获得有权限这样做的人的邀请，就不可能“向上”移动 DAG。这意味着，例如，如果我们开始使用这些频道发布直播，我们可以为此创建一个 #public 频道
#zed
- > #livestreaming
- > #search-and-replace
- > #design
- > #livekit 🔗
- #public
- #linux-support
- #windows-support
在这个#公开 频道中，我们可以指定社区成员为版主，或者生成只读链接。而且我们无需担心#公开 频道中的人能够访问 Zed 的任何内容。
下周，我将讨论我们如何实现此功能的一些技术细节。
（请注意，我所说的一切都可能会发生变化，我们仍在尝试哪种方式感觉最好，哪种方式效果最佳 :D）
Julia
我们一直想做的一件重要事情是让用户能够为 Zed 添加自定义语言支持。 由于涉及的复杂性，我们已经推迟了一段时间，但是本周我得到了开始进行这项工作的批准。 我们现在从添加自定义语言服务器开始，因为这将让我们在添加可扩展的 tree-sitter 语法支持之前弄清楚一大堆 WASM 的事情。 这意味着本周我得以阅读和试验许多很酷的 WebAssembly 内容。 仍然有很多工作要做，但我对我们前进的方向感到兴奋！