Zed Weekly: #21 — Zed 博客

Kirill

现在，大部分关于初始 prettier 集成的工作已经完成：我想编写更多的测试并进行更多的尝试。不幸的是，Sonoma 和我们的协作服务器不能一起工作，所以我无法正确地证明我们 prettier 支持的远程集成部分是有效的。因此，另一个绕行来修复特定于平台的回溯问题，耶。

作为本周 prettier 集成的副作用，LSP 服务器现在可以更好地显示日志：Zed 中使用的每个服务器现在都显示这些日志，包括它们的 stderr 日志。除此之外，我正在慢慢回到小任务：本周切换文件查找 (cmd-p) 变得稍微符合人体工程学，并且嵌入提示切换现在仅在有用时显示。

Marshall

大家好！在接下来的几周里，我将与 Nate 密切合作，在即将发布的 gpui 版本之上重建 Zed UI。

到目前为止，我的一个重点是设置一个 storybook，用于隔离渲染我们的新 UI 组件。这里的目标是提供一个快速的迭代循环，而无需启动整个 Zed。

这是一个基本 story 的示例

use strum::IntoEnumIterator;
use ui::prelude::*;
use ui::{Icon, IconElement};
 
use crate::story::Story;
 
#[derive(Element, Default)]
pub struct IconStory {}
 
impl IconStory {
    fn render<V: 'static>(&mut self, _: &mut V, cx: &mut ViewContext<V>) -> impl IntoElement<V> {
        let icons = Icon::iter();
 
        Story::container(cx)
            .child(Story::title_for::<_, IconElement>(cx))
            .child(Story::label(cx, "All Icons"))
            .child(div().flex().gap_3().children(icons.map(IconElement::new)))
    }
}

我们可以通过 storybook CLI 运行这个 story

cargo run -p storybook -- elements/icon

然后会显示这个

除了基础设施工作之外，我还深入研究了这些新 UI 组件的实现。我们本周取得了很大的进展，并将在不久的将来分享更多内容！

这周在 Vim 方面，我发布了命令面板的预览版！最初的用户反应非常令人兴奋，很高兴能结束这个最受需要的功能。我还花时间添加了一些更多的 Vim 相关的文档，并为 Zed 特定的功能添加了一些 Vim 风格的快捷键绑定。完成这些工作，以及过去 3 个月里超过 60 个小的错误修复、功能添加和生活质量的改进之后，很遗憾，是时候停止把 100% 的时间花在 Vim 模式上了。我仍然希望继续修复报告的错误，并处理（仍然大量的）积压工作，但在一段时间内将不会有重大的改进。

这将让我可以参与帮助 Max 和 Mikayla 开发 Zed 的协作功能。无缝协作的承诺是 Zed 构建开发环境的方法中最令人兴奋的事情，我期待着深入研究并使其变得更好。

Joseph

在过去的一周里，我一直在到处奔波，但本周更令人满意的一项任务是优化我们仪表板中的一些图表，这些图表速度很慢和/或占用大量内存。特别是，一个图表在给定的 Clickhouse 云机器上运行需要几分钟，有时会超出默认的内存限制并报错。我能够将执行时间减少到 10 秒以下，并大大减少内存使用量。

Kyle

对于 Zed 的 AI 来说，这是重要的一周，我们将初始语义索引发布到了稳定版，以及项目搜索中的语义模式。反馈非常积极，并且摆脱了这些障碍，我们现在可以继续开发利用这项技术的更令人兴奋的功能。其中之一就是将索引与我们的内联助手集成。本周，我为它连接了初始测试，允许我们生成能够理解和访问我们代码库的代码。我对这些初始测试印象非常深刻，我认为它为 Zed 未来的功能打开了很多扇门。令人兴奋的东西，希望我们很快会发布一篇博客文章，介绍构建类似这样的东西所面临的一些技术挑战，以及对未来的少量预告。

Julia

我这周做的一件有趣的事情是和 Conrad 一起研究我们的非等宽字体光标移动。想象一下，文本可以放在一个完美的等宽网格中，一切都变得有意义，这很好，但不幸的是，世界上的语言使这变得非常复杂。在单个缓冲区中混合了多个书写系统（称为脚本）的情况下，文本系统必须对不同的文本部分使用不同的字体。这些不同的字体很可能在相同的字体大小下具有不同的宽度。即使使用的字体包含所有的字素，它们中的一些自然会更大，以便显示更多的细节或具有不同的形状；常见的嫌疑对象是表情符号和汉字。

所以我们有一个可能或可能不包含未对齐字素的缓冲区。即使所有的字素都完美地网格对齐，情况也会变得更糟。字素是 Unicode 中用于表示单个可视“字符”的概念。通常方便地将码位视为字符，但这与我们人类倾向于推理字符的方式不太准确。类似于 UTF-8 如何将单个码位编码为一到四个字节，一般的 Unicode 将一个字素编码为一个或多个码位。

我最喜欢的例子是家庭表情符号的许多变体 👩‍👩‍👧‍👦。根据您选择的编辑器如何处理退格键，您可以一次退格一个家庭成员，直到整个表情符号消失。这是因为它由每个家庭成员的一系列码位组成，这些码位由一个称为“零宽度连接符”的特殊码位分隔。

最后，我们有真正的狂野情况，比例字体。在使用非等宽字体的缓冲区中，所有的赌注都无效，所有的对齐都消失了。大多数代码编辑器对此处理得不是很好，包括 Zed。这是有道理的，因为看到用户故意使用非等宽字体来查看和编辑代码是非常奇怪的。然而，有一些人确实喜欢使用比例字体进行编码，我个人就是其中之一。所以这并不常见，但也不是闻所未闻。

当执行垂直光标移动时，大多数编辑器会尝试保持相同的水平位置。如果仅基于码位，或者更糟的是，像 Zed 目前使用的那样基于字节偏移进行幼稚的光标定位，则在上述情况下上下移动光标时，此水平位置可能会不可预测地跳动。

解决方案是尝试保持适当的水平位置，而不是任何类型的技术偏移。通过将预期的水平位置视为与鼠标单击相同的方式，当光标在潜在未对齐的内容中垂直移动时，我们可以保持更自然的水平位置感。缺点是它使光标移动在计算上更加昂贵和复杂，这就是为什么大多数编辑器不这样做。

这周，Conrad 和我在这项改变上取得了很大的进展。他会继续推进，但我们已经接近一个相当令人满意的结果。这项改变会带来多大的性能损耗，以及我们如何改进它还有待观察。所以，你可能需要等待一段时间才能在发布版本中看到它，甚至可能看不到。但我对我们所看到的改进感到兴奋！:)