Joseph
本周主要围绕添加代码/仪表板来跟踪 Zed 的 CPU 负载和内存消耗。我们希望更具体地了解有多少用户正在经历异常的使用水平，并能够更容易地调查这些情况。
Piotr
本周我一直在努力集成 Vue.js LSP 和 tree-sitter 查询；在此过程中，我探索了 LSP 的语义高亮协议，这看起来是一个很棒的未来功能。截至今天，我有一个用于 Vue 文件的语法高亮的工作版本，因此下周我计划从您的角度出发，解决所有问题，使其美观。 :)
Marshall
本周我继续致力于新的 UI 系统。我花了一些时间与 Nathan 一起研究即将推出的 GPUI 版本，这确实增强了我对该库的理解。我还开始了将 Nate 和我目前构建的 UI 组件迁移到新版 GPUI 的过程。
Conrad
这周我主要深入研究了 Zed 的协作功能。首先，消除了一些加入频道和共享项目时最明显的粗糙之处：您现在可以在标题栏中看到谁在主持共享项目，并且关注应该会更加可靠。
下一步是为 Zed（公司）以外的人建立一个机制来帮助我们构建 Zed（编辑器）。我们正在构建公共访问频道，作为其中的一部分，添加了对应用程序本身的深度链接的支持。在即将发布的版本中，您只需给他们一个链接即可邀请人们加入频道。
就个人而言，我还写了一篇关于我学习 Rust 经验的博客；并且我正在努力恢复每两周写博客的习惯（我上次保持这个习惯是在 2012 年 :D）。如果您有兴趣，可以阅读What does = do in Rust? 的详细信息。
Antonio & Nathan
我们联合起来共同改进 GPUI，本周我们主要致力于将 Metal 渲染器移植到新版本，并借此机会进行创新和清理。作为这项工作的一部分，我们现在已切换到使用 plane-split 来确定原语的绘制顺序。渲染器唯一缺少的部分是 Bézier 曲线的绘制，我们应该在下周初完成。
新 GPUI 的另一个很棒的方面是，现在可以从多个线程访问实体。但是，某些操作（例如与大多数本机 UI API 交互）仍然需要从主线程执行。GPUI 应用程序中的大多数函数/方法都采用“上下文”，这本质上是对系统中整个状态的引用，并允许用户与应用程序、窗口和其他实体进行交互。本周我们引入了一个新的 MainThread<T: Context>(T) 类型：当在主线程上时，每个上下文都将围绕这个新类型进行包装，这确保了我们可以以线程安全的方式调用这些本机 API。
Mikayla
频道真的开始成型了！本周我一直在努力为我们的缓冲区和聊天添加更改通知，所以你实际上可以看到什么时候有东西要读。但是，在这个过程中，我们的频道变得有点笨拙，请参阅 我们在频道 UI 截图中有多少内容。当我们推进通知和公共频道等核心功能时，我们也在退后一步，重新思考此功能的核心理念。从根本上讲，我们有两个用例
- 技术团队的内部项目管理。这就是为什么我们有频道笔记和像文件系统（有向非循环图或 DAG）这样的结构。
- 内部项目沟通，如 Slack 或 Discord。这是很多聊天和通知风格功能出现的地方。
但这两种用例在根本上相互冲突。项目管理是关于有效组织信息和显示长期信息。将它塑造成 DAG 允许您索引到您可以考虑项目结构的所有方式。例如，一项新功能可能包含与后端、前端和设计团队对应的部分。每个人都需要知道他们各自的问题部分，并且需要互相监督以协调他们的努力。强迫像“API 设计”这样的文档拥有一个唯一的“所有者”（后端或前端）会给从根本上是多方谈判的过程注入不必要的摩擦。
与此同时，快速访问不确定信息是最好的沟通方式。仅仅为了弄清楚在哪里提问而不得不浏览文档层次结构是一种痛苦的体验。最好有一个简单的、粗粒度的结构，比如 Slack 的频道，它可以让你足够接近你消息的最佳接收者，这样人类社交图就可以接管。
现在我们的频道有点处于两全其美的最糟糕境地。我们的频道笔记隐藏在一个通常不可见的按钮后面，没有关于其用途的 UI 指南，有很多不同的地方可以交谈，却无法知道谁在阅读什么，而且仅仅是看一眼就让人不知所措。
那么我们如何简化这个问题呢？将两个用例解绑到它们最有用的地方。
所以有点像这样
Zed Industries
#design
📄 Zed UI rewrite tracker 🔗
📄 simplifying channels 🔗
📄 Channel use cases
#gpui2
📄 Zed UI rewrite tracker 🔗
#livestreaming
📄 simplifying channels 🔗
📄 Channel use cases
📄 notifications
📄 public channels
点击聊天频道会打开聊天窗口。点击文档会打开文档。频道笔记仍然可以存在于多个位置，但聊天频道则不会。项目管理和文档存储功能会被隐藏起来，直到你需要它们时才会出现，而通信功能则位于最前面和中心位置。这将与一个很像 Slack 的“浏览频道”和“频道成员”功能的系统配对，因此你甚至不需要看到与你无关的频道。我对这种组织的看法可能很简单，就像
Zed
> #design
\/ #livestreaming
📄 simplifying channels 🔗
📄 Channel use cases
📄 notifications
📄 public channels
希望这将使它更容易导航和使用。我们可能会在未来一两周内研究此功能的某些变体，敬请关注！
Julia
本周我大部分时间都在埋头完善自动完成文档的收尾工作。我们已经有了用于显示悬停弹窗的 Markdown 渲染器，我的初始演示有效地复制粘贴了该代码。我本周完成的一项有趣的工作是将其整理成可重用的 API，这使我能够通过分离解析和渲染阶段，更轻松地预处理文档 Markdown。
渲染是指构建元素树，该元素树实际上被光栅化到屏幕上，并且以前悬停弹出窗口会在每次需要重建其元素子树时重新解析其 Markdown。这没有问题，因为我们相对不频繁地这样做，并且 Markdown 通常很小，但是我在完成文档时无法这样做，因为我们需要允许在尚未加载特定语言的语法的情况下对 Markdown 中的代码块进行语法突出显示。我尝试了一种粗略的解决方法来处理这个问题，但这会在首次显示完成的文档时添加闪烁，这是不可接受的。
此外，将这两个步骤合并意味着我必须做更多的工作才能将编辑器样式暴露给这些处理 Markdown 的代码路径，以便它们能够查找各种 Markdown 部分应如何使用所选主题、字体和缩放比例显示。通过对其进行大量修改，我已经能够显着提高 UI 项目处理 Markdown 的代码质量，并且作为一个很酷的副作用，它们现在应该渲染得更快一些了！ :)
Max
本周，Mikayla 和我完成了向每个 Zed 频道添加状态指示器的功能，这样你就可以看到哪些频道对其频道笔记有更改，或者有你尚未看到的新聊天消息。
星期四，我修复了 Zed 的关注功能中的一个长期存在的错误，即如果视图最初是由他们关注你创建的，则你无法跟随协作者进入该视图。 此错误是由于我们尝试在对等方相互关注时防止无限循环而引起的，因此我必须找到一种限制性较小的方法来防止无限循环。
在那之后，我开始做通知功能。为了使频道消息更有用，我们需要能够使用 @ 提及其他用户，并确保他们收到通知。 通知可能会进入另一个侧面板，类似于协作和聊天面板。