基里尔
目前，Prettier 初始集成的大部分工作已经完成：我想编写更多测试并更多地使用它。不幸的是，Sonoma 和我们的协作服务器不兼容，所以我无法正确证明 Prettier 支持的远程集成部分是否有效。因此，又一次绕道去修复平台特定回溯的问题，太好了。
作为本周 Prettier 集成的副作用，LSP 服务器现在可以更好地显示其日志：Zed 中使用的每个服务器现在都显示这些日志，包括它们的 stderr 日志。除此之外，我正在慢慢回到一些小任务上：本周切换文件查找 (cmd-p) 变得更符合人体工程学，并且内嵌提示切换现在只在有用时显示。
马歇尔
大家好！接下来的几周，我将与 Nate 密切合作，我们将基于即将发布的 gpui 版本重建 Zed UI。
到目前为止，我的一个主要重点是建立一个故事书，用于独立渲染我们的新 UI 组件。这里的目标是提供一个快速的迭代循环，而无需启动整个 Zed。
这是一个基本故事的示例
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 运行这个故事
cargo run -p storybook -- elements/icon然后它会向我们展示这个
除了基础设施工作之外，我一直在深入研究这些新 UI 组件的实现。我们本周取得了很大进展，很快就会有更多内容与大家分享！
康拉德
本周在 Vim 中，我将命令面板发布到预览版！用户的初步反应非常令人兴奋，很高兴能完成这个最受欢迎的功能。我还花时间添加了一些 Vim 特定的文档，并为 Zed 特定的功能添加了几个具有 Vim 感觉的键绑定。完成这些工作，以及过去 3 个月内 60 多个其他小错误、功能和生活质量改进之后，遗憾的是我不得不停止将 100% 的时间花在 Vim 模式上。我仍然希望继续修复报告的错误，并处理（仍然广泛的）待办事项，但在一段时间内，主要改进会减少。
这将使我能够协助 Max 和 Mikayla 解决 Zed 的协作功能问题。无缝协作的承诺是 Zed 构建开发环境方法中最令人兴奋的事情，我期待着深入研究并使其变得更好。
约瑟夫
过去一周我一直有点忙乱，但本周最令人满意的工作之一是优化仪表板中一些缓慢和/或内存密集型图表。特别是其中一个图表在给定的 Clickhouse 云机器上运行需要几分钟，有时会超出默认内存限制并出错。我成功地将执行时间缩短到 10 秒以内，并大大减少了内存使用量。
凯尔
对于 Zed 的 AI 来说，这是一个重要的一周，因为我们将初始的语义索引和项目搜索中的语义模式都发布到了稳定版。反馈相当积极，解决了这个问题后，我们现在可以着手利用这项技术开发更多令人兴奋的功能。其中之一是将索引与我们的内联助手集成。本周，我为这项功能连接了初步测试，使我们能够生成理解并能够访问我们代码库的代码。这些初步测试给我留下了深刻的印象，我认为它为 Zed 的未来功能打开了很多大门。令人兴奋的事情，希望我们能尽快发布一篇博客文章，介绍构建类似系统的一些技术挑战和未来的一些预告。
茱莉亚 (Julia)
我本周做的一件有趣的事情是与 Conrad 一起研究我们的非等宽光标移动。想象文本可以放在完美的等宽网格中，一切都有意义，这很好，但不幸的是，世界语言使其复杂得多。在单个缓冲区中混合使用多种书写系统（称为脚本）时，文本系统必须为文本的不同部分使用不同的字体。这些不同的字体在相同的字号下很可能有不同的宽度。即使使用的字体包含所有字形，其中一些字形自然会更大，以便显示更多细节或具有不同的形状；常见的嫌疑是表情符号和汉字。
因此，我们有一个可能包含或不包含未对齐字形的缓冲区。即使所有字形都完美地网格对齐，情况仍然会变得更糟。字形是 Unicode 中表示单个视觉“字符”的概念。通常方便地将码点视为字符，但这与我们人类倾向于对字符进行推理的方式不太准确。类似于 UTF-8 将单个码点编码为一到四个字节，Unicode 通常将一个字形编码为一个或多个码点。
我最喜欢的例子是家庭表情符号的许多变体 👩👩👧👦。根据您选择的编辑器如何处理退格键，您可以一次退格一个家庭成员，直到整个表情符号消失。这是因为它由每个家庭成员的码点序列组成，由一个特殊的码点“零宽度连接符”分隔。
最后，我们有真正的极端情况，即比例字体。在使用了非等宽字体的缓冲区中，所有的假设都不成立，所有的对齐都消失了。大多数代码编辑器都不能很好地处理这种情况，包括 Zed。这很合理，因为用户故意使用非等宽字体来查看和编辑代码是极其奇怪的。然而，有一些人确实更喜欢比例字体来编写代码，我个人就是其中之一。所以这种情况不常见但并非闻所未闻。
在执行垂直光标移动时，大多数编辑器都试图保持相同的水平位置。如果光标定位仅基于码点，或者更糟糕的是，基于 Zed 当前使用的字节偏移量，那么在这种情况下，当光标上下移动时，水平位置可能会不可预测地跳动。
解决方案是尝试保持一个适当的水平“位置”，而不是任何技术偏移。通过将这个预期的水平位置像鼠标点击一样处理，我们可以在光标垂直穿过可能未对齐的内容时保持更自然的水平位置。缺点是它会使光标移动的计算成本更高、更复杂，这也是大多数编辑器不这样做P 的原因。
本周，Conrad 和我在这项改变上取得了很大进展。他正在继续推进，但我们已经接近一个相当令人满意的最终结果。至于这将带来多少性能开销以及如何改进，还有待观察，因此您可能需要一段时间才能在发布版中看到它（如果能看到的话），但我对我们所看到的改进感到兴奋！:)
马克斯
本周，我一直在努力使协作时的工作更直观。以前，关注功能仅限于单个项目，无法在共享项目之外关注他人。但现在，我们引入了一项名为频道笔记的功能，它是不属于项目的可协作编辑缓冲区，因此即使没有共享项目，也能关注这些视图会很有用。所以我们正在实现这一点。
我们还在改变协作者的颜色分配方式，使其在整个通话过程中保持一致，而不是在每个共享项目中都不同。
米凯拉
刚从 Strangeloop 和随后的 Local First 非会议回来，我见到了 Conrad :D。除此之外，我一直在为我们的频道功能添加变更通知。检测频道笔记的变更非常容易，因为我们对所有操作都使用 CRDT，我们只需保存为每个协作方发送的最后一个 lamport 时间戳值。但是，批量执行这种操作以解决 N+1 查询问题，已经变成了一个特别棘手的多步骤 ORM 连接。如果选择保留这些代码，我将尝试在下周发布截图。
内森
姗姗来迟。很抱歉连续几周错过这些。我一直在埋头对 GPUI 进行重大改进。虽然 Nate 一直努力使用我的初始原型来构建新布局系统中的 UI，但我一直在努力重新审视系统核心的假设，并运用我们过去几年学到的一些东西来简化 API。对我来说，在向世界分享 GPUI 之前，把这些事情做好很重要。我真的很期待。