约瑟夫
本周的主题主要是添加代码/仪表盘，以跟踪 Zed 的 CPU 负载和内存消耗。我们希望更具体地了解有多少用户正在经历异常的使用水平，并能够更轻松地调查这些情况。
Piotr
本周我一直在致力于集成 Vue.js LSP 和 tree-sitter 查询；在此过程中，我探索了一种使用 LSP 进行语义高亮的协议，这在未来看起来会是一个很酷的功能。截至今天，我有一个 Vue 文件的语法高亮工作版本，所以下周我计划站在您的角度，解决所有问题，使其“更好”。:)
马歇尔
本周我继续进行新的 UI 系统的工作。我花了一些时间与 Nathan 合作开发即将发布的 GPUI 版本，这确实增强了我对该库的理解。我还开始将 Nate 和我到目前为止构建的 UI 组件迁移到新版本的 GPUI。
康拉德
本周我主要深入研究了 Zed 的协作功能。首先是消除加入频道和共享项目方面最明显的粗糙之处：您现在可以在标题栏中看到谁正在主持共享项目，并且跟随功能应该更加可靠。
下一步是建立一种机制，让 Zed（公司）以外的人帮助我们构建 Zed（编辑器）。我们正在构建公共访问频道，并作为其中一部分添加对应用程序内部深层链接的支持。在即将发布的版本中，您将能够通过给他们一个链接来邀请人们加入频道。
在个人方面，我还写了一篇关于我学习 Rust 经历的博客；我正在努力恢复两周一次的博客习惯（我上次坚持是在 2012 年 :D）。如果您有兴趣，可以阅读Rust 中“=”的作用是什么？的详细内容。
Antonio 和 Nathan
我们齐心协力改造 GPUI，本周我们主要致力于将 Metal 渲染器移植到新版本，并借此机会根据需要进行创新和清理。作为这项工作的一部分，我们现在已改用 plane-split 来确定基元的绘制顺序。渲染器唯一缺少的部分是 Bézier 曲线的绘制，我们应该在下周初完成。
新 GPUI 的另一个很酷的方面是实体现在可以从多个线程访问。然而，某些操作，例如与大多数原生 UI API 交互，仍然需要从主线程执行。GPUI 应用程序中的大多数函数/方法都采用一个“上下文”，它本质上是对系统中整个状态的引用，并允许用户与应用程序、窗口和其他实体进行交互。本周我们引入了一种新的 MainThread<T: Context>(T) 类型：在主线程上时，每个上下文都将包装在此新类型中，这确保我们可以以线程安全的方式调用这些原生 API。
米凯拉
频道功能正逐渐成形！本周我一直在为我们的缓冲区和聊天添加更改通知，这样您就能看到何时有新内容可读。然而，在此过程中，我们的频道变得有点笨重，请参阅我们频道 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 部分的外观。通过大量重构，我大大提高了需要处理 Markdown 的 UI 项的代码质量，作为一个很酷的副作用，它们现在应该渲染得更快一点了！:)
马克斯
本周，Mikayla 和我完成了为每个 Zed 频道添加状态指示器的工作，这样您就可以看到哪些频道的频道笔记或新的聊天消息有您尚未查看的更改。
周四，我修复了 Zed 跟随功能中一个长期存在的 bug，即如果您无法跟随协作者进入一个视图，如果该视图最初是由他们跟随您创建的。这个 bug 是由于我们试图防止当同行相互跟随时发生无限循环，所以我不得不寻找一种限制较少的无限循环预防方法。
之后，我开始着手处理通知。为了使频道消息更有用，我们需要能够 @ 提及其他用户，并确保他们收到通知。通知可能会进入另一个侧面板，类似于协作和聊天面板。