这是我与 Zed 的三位联合创始人 Nathan、Max 和 Antonio 的第四次对话。请阅读之前的对话。
这次我们讨论了 Zed 背后的产品理念，它在编辑器和 IDE 之间的定位，它是否更倾向于 Emacs 或 Vim，创始人绝不会添加到 Zed 中的内容，他们如何决定什么是 Zed 的特性，什么不是，他们如何看待扩展和脚本化。我们还得到了咖啡机支持是否会出现在 Zed 中的答案。
以下是一个小时对话的编辑稿。我尽量保留了意图和意义，同时去除了语调词、停顿和更正，这些构成了深入的对话。
（您可以在我们的 YouTube 频道上观看完整的对话。）
Thorsten：你认为 Zed 在 IDE 和编辑器之间，例如 Visual Studio 和 Nano 之间，处于什么位置？它应该落在哪里？
Nathan：我的意思是，对于我来说，IDE 总是有一种特定的含义，这种含义来自我过去使用过的 IDE，它们有很多功能，但你似乎总是需要为这些功能付出代价，要么是缓慢的 UI，要么是杂乱的 UI，或者两者兼而有之。
似乎 JetBrains 在简化 UI 方面做得更好，但它仍然没有像我通常所说的编辑器那样快。例如 Vim，或者以前的 TextMate。我记得在我职业生涯早期，在 TextMate 中编写 Ruby 与最终采用 RubyMine 或其他工具之间的对比，前者虽然没有很多帮助，但至少速度很快。而后者虽然获得了所有这些功能，但却对延迟感到沮丧。
所以这始终是一种权衡。我的梦想一直是两者兼得，拥有一个功能极其强大，但同时又具有简洁简约的氛围，并且速度超快的工具。超快的速度和强大的功能很难结合在一起。
我的意思是，我几乎把我的职业生涯都花在了达到我们可以将它们结合起来的地步。但这就是目标。
但我始终倾向于 UX 上的极简主义，我用的类比是 Model S 特斯拉。你走近它们，门把手会从侧面弹出。在不需要时或在会产生阻力时，它会被隐藏起来，但在恰当的时刻可用。这就是梦想。
Thorsten：性能和尽可能多的功能，但不能以牺牲性能或极简主义或臃肿为代价。
Nathan：是的，不能以牺牲速度和噪音为代价。让我的代码始终处于中心位置，并且不要在我试图实现的基本行为（即编辑代码）之间引入延迟。无论如何，这种基本体验都需要快速。
Antonio：我选择的第一门编程语言是 C#。我曾经是 Windows 用户。所以我记得打开 Visual Studio，不是 Visual Studio Code，而是 OG Visual Studio，它们都有一个加载屏幕，因为启动时间太慢了。那可能是 Visual Studio 2005，正在加载，你知道，DLL one, two, three, blah, blah。
和 Nathan 一样，从那到使用 TextMate 之间的对比，我认为我是在那之后使用的 TextMate，这太疯狂了。
我认为 IDE 和编辑器之间的区别，我不知道，我没有真正考虑过它为什么存在。我希望拥有 IDE 的所有功能，我认为编辑器有可能拥有所有这些功能。我的理论是，我刚刚形成这个理论，所以它还没有经过深思熟虑，就是将它们全部结合起来是可能的。我的感觉是，那些缓慢的 IDE 只是堆砌东西，在顶部添加东西，用螺栓固定它们的结果。“哦，我们可以有这个功能。好的，让我们添加它。我们可以有另一个功能，好的，让我们添加它。”
然后你最终会得到一个复选框列表和彼此没有真正集成的东西。所以你拥有所有这些功能，但它们没有经过垂直思考。
我不知道这是否属实，但这始终是我给人的印象。“哦，让我们添加另一个复选框。”但这并不是我们 Zed 想要的氛围。
Thorsten：也许这是一个陷阱问题，因为 IDE 和编辑器之间的界限——现在已经不是很明确了，不是吗？ 10 年、15 年前，你有 Nano：没有语言感知功能，甚至没有语法高亮。然后是另一边的 Visual Studio。但是现在有了语言服务器、tree-sitter 以及所有你可以插入到编辑器中的东西，事情发生了变化，我想有趣的是：我们想落在哪里？就像你说的 Nathan，我们想做出哪些权衡，我们将不会采用 IDE 拥有的哪些东西，或者我们想采用哪些东西？
Max：自从编辑器和 IDE 之间存在真正巨大差异的时代以来，情况已经有了很大的改善。我认为语言服务器协议帮助了很多。 tree-sitter 帮助一些编辑器变得更智能，并且对语法有基本的了解。
我认为我们拥有的架构，其中编辑器具有语法感知能力，并且为了语义理解而调用未与任何一个编辑器耦合的语言服务器，这是一个相当不错的架构。
当人们说“编辑器 vs. IDE”时，通常在编辑器阵营中，他们将 Vim 和 Emacs 作为典型的编辑器，但即使是这些工具现在也具有 LSP 支持和 tree-sitter，所以我有点认为我们正在融合到一个更好的设计中，编辑器具有语法感知能力。不仅仅是 Zed，而是所有编辑器。
但我仍然认为还有改进的空间。我仍然在 IDE 中享受的一个 UX 功能，即使它不会让我使用它们，就是重命名变量的操作。在 IntelliJ 中，它会突出显示所有出现的位置，就像你正在实时编辑其他位置的名称一样。我记得那是我在 Zed 中实现重命名功能时想到的事情。他们使用所有内置的语言分析来做这件事非常酷，我们探索了这样做。
我们确实将语法感知与 tree-sitter 和我们可以发送到语言服务器的重命名调用结合在一起。在大多数情况下，这非常好，可以给你你想要的东西。它并不能让我们做 IDE 所做的所有花哨的事情，但也许有空间来扩展 tree-sitter 可以做什么以及语言服务器可以做什么，以便让我们做类似的事情。更好。
Thorsten：假设性能不是问题，并且，用 Nathan 的类比来说，一切都可以隐藏起来。你是否想到 IDE 世界中的任何东西是你永远不会添加到 Zed 中的，因为你认为它不适合在这里？例如：“这不是 Zed 的东西，这是 IDE 类型的东西。”
Nathan：我暂时想不出来。 IDE 这个词对我来说一直很奇怪。我明白区别，但我不知道，它是一个代码编辑器。你只是想完成工作，是的，我想是这样。那么整合开发环境意味着什么呢？
我想，我们正在添加的一件事，也是许多 IDE 没有很好地集成到开发体验中的一件事是，其他人的存在以及我们正在协作的事实。所以我认为我们通过整合更多的关注点来延续 IDE 的愿景。
因为这就是 IDE 的想法，对吧？它不像我在这里编辑，然后我有我的终端，我在来回切换，我正在使用这种混合的工具。它都集成到一个体验中。所以我认为协作可以包含在其中。但是不，我唯一想从 IDE 中抛弃的东西是缓慢和无处不在的按钮。是的。
Max：所有按钮。无处不在的按钮。
Thorsten：还有另一种编辑器：一端是 Emacs，另一端是 Vim。当然，两者之间有很多，但在我看来，Emacs 意味着：编辑器作为操作系统。你拥有这一件事，你在这里做所有的事情。这就是力量倍增器。因为你始终在 Emacs 中，你的 shell 在 Emacs 中，你的编译器在 Emacs 中运行，你的电子邮件，你的咖啡机，一切都在 Emacs 中。这意味着你永远不必离开它，而且你会更有效率，对吧？写电子邮件，煮咖啡。另一方面，Vim...有这篇文章，我想那是 10 年前写的，在里面他们说，Unix 是 IDE，Vim 是这个环境中的一个工具。这就是它的力量来源。它只是众多工具之一。所以当你你想要整合更多时，这是否意味着你更倾向于 Emacs 方面的东西，并说力量来自我们把更多的东西放到 Zed 中，例如，协作？
Nathan：是的，我的意思是，我不希望……我想揭示命令行存在的事实，我喜欢那个世界。我讨厌存在一些深奥的项目文件，其中包含所有细节的世界。这非常像 Xcode，对吧？其中有一个 Xcode proj 或其他东西，一切都通过点击来完成。我不想这样。
我不想用按钮替换命令行体验。我不认为这是一件大事。我喜欢接近机器，并用语言与机器交流。我希望 IDE 意识到并与终端的存在和命令行的存在清晰地集成，并避免我们尝试以这种视觉范式定义一切的状态。成为 Unix 的自然延伸，Unix 哲学和补充，我认为这更符合我的速度。
但如果我可以直接按下一个快捷键，而不是切换到终端，按向上键再按回车来运行测试（这是 Kirill 和 Piotr 正在努力的方向）？我会选择前者，但我不想对这件事隐瞒，它本质上只是在运行一个命令。
Thorsten: 这是一个很好的区分。这可能也是我将 IDE 与之关联的一件事：你启动它，然后点击那个绿色的播放按钮，你不知道发生了什么，但有人告诉你这是运行它的方式。然后当出现问题时，你不知道那里到底发生了什么。
Nathan: 我喜欢这种精简的感觉，但同时也要保持效率。我不想有魔法。
Max: 我不想抽象化，就像 Nathan 说的，我不认为我们想要抽象化像 Git 和 cargo test 这样的东西，但我也认为有时使用工具最有效的方式不是通过命令行。我对将 Unix 作为 IDE 的愿景持怀疑态度，认为对于任何人来说，无论他们的肌肉记忆有多好，最快的用户体验都是切换到 shell。如果他们想查找某些东西，就切换到 shell 并执行命令行搜索。我认为通常情况下，通过集成到工具中，我们可以拥有比在终端中运行终端编辑器更快、键盘驱动的工作流程。
Nathan: 但我不认为我们会在 Zed 中构建一个电子邮件客户端。我可以看到在 GPUI 中构建一个电子邮件客户端，因为它们都让我抓狂。我的意思是，这绝对不是首要任务，而且...
Max: 我可以看到一台咖啡机。
Antonio: 哈哈哈
Nathan: ...在添加任何东西之前我会非常小心，因为我担心它们会分散我们的注意力。因此，如果 Zed 变得足够可扩展，以至于有人可以构建一个电子邮件客户端，那就太好了。但这似乎还有很长的路要走，而且根本不是我们的优先事项。我们的首要任务是编写软件。
Thorsten: 扩展如何融入？因为我认为可能存在扩展破坏这个概念的危险，你添加了太多的扩展，人们会说，现在很慢，UI 中有 15,000 个按钮，然后每家公司都有一个 Zed 默认插件配置，我们最终会得到 50,000 个按钮，启动需要 30 秒。你如何看待扩展的引入？
Max: 我不想说有什么我们不会让扩展做的事情，但我们最初的几个扩展里程碑更多的是关于插入到现有的 Zed 功能中，显然第一个是添加语言。
我们还在添加这个任务系统，扩展可以帮助你发现要运行的任务并将它们暴露给你。这是一个现有的工作流程，所有 Zed 用户都有，并且扩展丰富了它。我们可以从中获得很多好处。或者，你知道，扩展让你编写对你来说是唯一的工作流程，例如打开文件、在某些文件中查找某些类型的代码、使用光标在某些文件中执行操作、进行可以让你个人更有效率的编辑。这是我现在对扩展的优先级，而不是添加任何新的 UI 或构建电子邮件客户端。
使用扩展构建一个 Zed 中甚至不存在的概念，我认为我们可能会做，但它不会像 Atom 那样，从一开始，一切都是一个扩展。我们所做的一切都必须可以作为扩展来完成，这是一种不同的方法。
Nathan: 我不认为拥有很多扩展就一定会很慢，但这将需要仔细设计 API 以及我们如何运行扩展。它们将在它们自己的 WebAssembly 运行时中，在它们自己的线程上隔离运行。我确实认为，如果我们曾经把一个扩展放在键入的关键路径上，我不知道我们是否会这样做，这样它就可以检查你插入的每个字符并执行一些操作。如果我们要这样做，我总是希望设置一个截止日期。我想我在其他场景中谈论过这个问题，扩展作者必须达到明确的性能限制，否则我们就会禁用该扩展。所以我认为有一些方法。
现在，当你说成千上万个按钮时，那是另一回事。但同样，当我们添加这些允许按钮显示的扩展点时，这将需要我们非常仔细地思考如何隐藏这些东西并避免混乱。但至少从性能上来说，就像 Atom 的问题一样，我们只是在主线程上运行了人们的扩展。再见，性能。我们不会再犯同样的错误了。
Antonio: 关于 macOS API，人们可以有很多说法，你知道，我当然可以对 Mac OS API 发表很多看法——有时与它们交互是一场噩梦——但想想 iPhone 和 iPhone 上的应用程序：你根本无法进入主屏幕并扰乱基本体验，对吧？我真的很喜欢这一点。你有很大的灵活性，对吧？但它是在不会降低整体体验的地方。
所以就像 Nathan 说的，这不仅是一项工程工作，我认为也是一项 UX 工作，即理解这些扩展点是什么，这些接缝是什么以及在哪里插入它们。但我喜欢以 Apple 方式进行操作的想法。
Thorsten: 这真的很难，不是吗？简单的方法，虽然仍然很难，就是限制很多东西，并说扩展只能做这个和这个，仅此而已。但是 Nathan，你上次提到过，我们确实想要类似脚本的功能，对吧？我们确实有像 tree-sitter 这样的东西，它可以让你以一种很好的方式修改代码或围绕它编写脚本。那么我们是否要公开其中的一些内容，但是要找到那个确切的点，在那里你给予足够的权力而又不会让整个事情崩溃，这难道不是非常困难的吗？
Nathan: 是的。但我不知道，我对我们目前使用 WebAssembly 的设计感到非常乐观，最终我们可以在 V8 隔离区中做同样的事情，或者...如果最终我们选择这种方式，那么 Python 应该有自己的等效方案。我们的整个应用程序是多线程的。我们在主线程和其他线程之间有非常明确的区别。我们有共享内存并发。
所以是的，这很难，但我们已经在技术选择上投入了大量资金，使其至少从性能角度来看是可行的。我不会轻视它，但我也认为，如果我们谨慎行事，我们有能力做好它。
从设计的角度来看，这很难。构建 API...我的意思是，我们真的从 Atom 那里学到了这一点。拥有一个扩展 API 真的很难。对其进行版本控制、发展它，这一切都具有挑战性。但我认为，在之前做过一次并犯了很多错误之后，我们完全有能力避免这些错误。而且我们拥有的基础非常牢固。
Thorsten: 当你说脚本功能时，你脑海中有什么？凭借 Zed 已经拥有的东西和 tree-sitter，如果它被公开，你可以在其基础上构建很多强大的东西。你认为脚本功能或扩展的第一个重大里程碑是什么？
Nathan: 我的意思是，如果 Emmet 可以实现就好了，因为很多人都想要它。所以这是一件事。
Thorsten: 因此，能够使用 tree-sitter API 或语法感知 API 或类似的东西来修改文本。
Nathan: 是的，我什至不知道 Emmet 需要在多大程度上具有语法感知能力，但显然这可能有助于确保我们在这个特定示例中，并在有意义的上下文中进行这些扩展。
对我来说，困难的部分是我的想象力在这方面有点不足，因为我不需要编写任何扩展，因为我可以直接在编辑器中做任何我想做的事情。
Antonio: 哈哈哈。
Nathan: 但也许你们有更好的想法。对我来说，这是一个阀门。我喜欢它的一点是我不知道人们会用它做什么。虽然这具有挑战性，但你确实需要构建一个 API，心中想着人们可以做什么。所以关于具体用例，我可能没有花足够的时间去思考。Max，你有什么更多的想法吗，在深入研究并开始使用它之后？
Max: 对于脚本，我可以想象自己想要拥有一些简单的命令，我可以运行：我在一个窗格中编辑一些文件，然后我运行一个命令，它使用 tree-sitter 和 grep 的组合来查找我所在文件的测试，并在另一个拆分窗格中打开它们，并将我的光标放在那里，滚动视图以显示测试。
诸如此类，例如移动、在项目中查找事物、在缓冲区中查找事物、使用正则表达式搜索、使用语法搜索、定位光标、可能进行编辑。
我可以想到很多你可以用相当少量的 API 做的事情，例如打开一个窗格，你可以找到打开的窗格，你可以进行搜索。我设想在不同的代码库中，人们会有一些他们经常做的事情。也许如果你正在处理 Rails 代码库，并且你想打开控制器测试的控制器，我现在甚至不记得了。我在 Vim 中有一些脚本可以做类似的事情。很多时候它只是用 grep。
我认为这对于人们的生产力很重要。我认为这很容易实现，因为你不需要为其构建自定义 UI。你只需要操纵编辑器和窗格的能力。实际上，很多生产力和脚本都是围绕这样的核心功能展开的。所以我想把这些 API 做好。
Thorsten: 几周前，一位用户说他们希望能够执行光标所在的任何函数。我们中的很多人的第一反应是，“什么，那是什么意思？” 但现在我们和用户交谈过后，我认为他们想要的东西类似于你在 Emacs 中拥有的东西，你可以将光标放在任何 S 表达式上，然后说“评估这个”。我认为我们可以使用 tree-sitter 做类似的事情，对吧？你可以说，“我在一个 Ruby 文件中，所以现在当我点击这个快捷键时，评估表达式或光标所在的任何东西。” 这种交互式的代码评估，语法感知的东西，会非常酷。
Nathan: 没错，就像引入 Kyle Kelly 一样。他已经研究了几天，看看获得 Jupiter 运行时支持会是什么样子？扩展 API 应该是什么样的？它可能不是构建 Jupiter 集成所需的一切，但它可能像，哦，这个存在，你可以联系并获取 tree-sitter，并调用这个其他 API 到一个有效且合适的运行时。是的，那太棒了。对我来说，我一直认为，人们自己解决问题的能力，从长远来看，会比我们试图为所有人解决问题更好。那样根本无法扩展。我们可以为 Python 构建一个 Zed 版本，并为... 我认为 JetBrains 就是走这条路。但我更愿意构建一个足够灵活的工具，让人们可以自己定制。
Atom 背后的梦想也是如此，我们只是把强度调到了 11。我希望也能把 Zed 调到 11，但也许它会在第四年达到 11，而不是第一年，我们在保持其他价值观不变的情况下，逐步达到目标。
Thorsten: 我不知道为什么我总是用这些维度来思考：内置所有功能 vs. 一无所有。现在 Zed 了解很多语言，了解很多语言服务器。人们甚至会说：“很好。我第一次在我的 TypeScript 项目中打开 Zed，它立即进行了自动完成。” 你认为这有限制吗？是否存在一个可以包含的核心功能的子集，但不能超过八个功能，10 个功能就有点太多了。其余的呢？你必须使用扩展。而且我认为这里最难的部分可能是每个人都需要不同的功能，无论他们在做什么。你对此有什么看法？
Antonio: 对我来说，每当我们包含一些东西在编辑器中，我就觉得我们做出了一种承诺，它将以某种方式工作。基本上，被归类为核心的是我们可以坚持的事情，我们可以对我们的用户履行承诺的事情。其他的一切，我就不知道了。就像你说的，每个人都需要不同类型的功能，是的，我不确定在哪里划清界限。
Nathan: 我认为那就是划清界限的地方。靠人力是不可能做到的，我们希望扩大我们的团队，但即使我们扩大了团队，我们的团队也不可能涵盖所有内容。但是，我们有可能涵盖很多内容。归根结底，人们只是想要一个按照他们想要的方式工作的编辑器。我想有一部分人真的很喜欢，你知道，用木头自己制作键盘，自己焊接，然后定制他们的编辑器。
他们只是想要一个编辑器工具包，然后把所有东西组合在一起。但我认为绝大多数人，包括我自己，如果他们只需打开它就可以使用，他们会更快乐。
我们正在努力找到正确的平衡点。我认为我们将许多语言纳入核心，因为我们还没有完全准备好可扩展性。其中一些将会被剥离出来，因为如果其他人（而不是我们）维护它，体验质量将会更高。所以这真的归结于这一点。我认为 Antonio 你说得对。我们会尝试，但我们可能会不时犯错，比如忘记将语言服务器更新到最新版本，或者我们没有使用正确的版本。但我认为这是正确的态度。如果它在核心中，那么它应该是好的。而且我们正在维护它。但我们只有这么多人，一天只有这么多小时。
Thorsten: 你在八周前也有这个想法吗？还是 Zed 开源后，所有的问题和拉取请求进来后才形成的？
Nathan: 哦，我们知道会是这样。我是这么想的，是的。这就是为什么可扩展性在路线图中排名靠前的原因，Linux 也是如此，因为这两者都有点像……我们知道人们会希望它能在 Linux 上工作，无论我们喜欢与否，或者当时是否安排了它，人们都会尝试在这方面做出贡献。所以我们想对此保持开放的态度。然后我们知道人们会尝试贡献一些东西，这些东西……
Jason Rudolph 过去曾在 Atom 与我们合作过，他说开源贡献有时就像有人给你一只免费的小狗。
因此，现在安排可扩展性是非常有意的。我们知道我们不想因为这些东西的准备情况而延迟开源，但我们也知道很快我们需要一种“安全阀”，来应对我们无法收养的免费小狗。
Antonio: 我想补充一点，这并不是说如果某些东西在核心中，它就不是一个开源项目。人们仍然可以帮助我们维护，提高其质量。只是入门门槛会稍微高一些。对于进入核心的任何内容，我们将更负责维护某种质量标准。
Thorsten: 这听起来没有那么有争议，但我们都参与了 这个 issue，其中键绑定从 Zed 键绑定更改为 VS Code 键绑定。这是昨天的事情，对吧？你们都在努力克服或者正在努力克服，我不知道你是否在本地改回了。但我认为这提出了一个有趣的问题：你是否会通过产品告诉用户（不是用这些词语），“嘿，你一直以来的做法是错误的”？或者“这里有一个更好的方法”？如果有人说“嘿，我们应该在编辑器中构建这个：我想在我的代码旁边显示图片，这样我就可以根据像素化的 JPEG 来输入代码”，或者诸如此类。你会说“不，我们找到了一个更好的方法来做到这一点。这不是我们想要的”吗？或者说，他们想要一个快捷方式来复制一行 5000 次，并且内置了这个功能。是否有任何事情让你觉得，这就是我们文本编辑的理念，我们知道它是什么，有些东西可能会与它发生冲突，而我们不希望它出现在 Zed 中。
Max: 在将我们的绑定切换为更像 VS Code 的情况下，即使这对我们所有人来说都很痛苦，最终获胜的是这样的想法：如果我们能与某些东西兼容，这样我们就不必向任何人解释任何事情，并且有人可以直接使用它，而不需要我们的任何解释，那么我们就选择它。
我非常重视这一点，这就是为什么即使我不喜欢新的键绑定，我们也合并了它。当 alt-up 不与任何东西冲突，并且 VS Code 没有 “选择更大的语法节点” 的默认绑定时，我们基本上添加了一个键绑定。所以我们选择了一个。但现在 VS Code 附带了该功能，并且他们有一个默认绑定。我认为我们使用它是有意义的，因为如果有人真的讨厌它，他们可以自定义它。我可能不得不这样做，因为到目前为止我无法适应 VS Code 的那一个。但我真的很看重与任何现有标准兼容。并不是说 VS Code 是一个标准，而是很多人都使用过它。因此，如果存在我们可以合作的东西，我倾向于采用它作为标准，融入生态系统。
Nathan: 是的，占据了 75% 的市场份额，或者更多。
但还有其他的事情，对吧？例如，VS Code，我认为他们还没有添加多缓冲区，这就是我们的查找体验 [意思是：这是你在项目中搜索的方式]。而且我个人更喜欢它，而不是底部的一个小菜单，一个面板，它向你展示位置，然后你跳转到不同的位置。
所以我们决定逆潮流而动，为此我们付出了一些代价。有些人甚至不明白这些东西是可以编辑的。它有点不太熟悉，与众不同。所以这并不是说我们永远不愿意……如果我们只是构建一个更快的 VS Code 克隆版本，我会非常失望。我们有自己的东西要表达，但它需要明显更好，或者对我们试图表达的东西非常重要，才能如此偏离人们的期望。但我想你也在问，我们对不同的做事方式有多大的接受程度，我认为这取决于具体情况。是的，我认为我们不会很快添加一个重复五次的命令。
Thorsten: 我认为多缓冲区是一个完美的例子。另一个关于 tree-sitter 的 “选择更大和更小的语法节点”，我认为 VS Code 没有这个功能，对吧？他们没有语法节点选择？
Max: 嗯，这就是让我如此困扰的地方。这个人打开了一个 PR，我认为这是一个很好的改变，他们说 VS Code 现在默认具有这些绑定，“选择更大的语法节点”。所以 Zed 应该使用相同的，但是，当我们第一次构建 Zed 时，VS Code 中没有这个东西。
Thorsten: 对我来说，这是一个例子，嘿，我们找到了一个更好的方法来做到这一点。现在，如果有人走过来并说，嘿，我希望以一流的方式构建这种其他方式。我们是否会反驳并说，不，实际上我们认为这是一种更好的方法？你所说的关于多缓冲区的内容表明，如果我们有信心找到了一种更好的方法来做某事，那么这就是我们将要做的事情。
Max: 是的，我认为我们对代码用户体验的愿景有一些看法。当存在可以采用的标准时，我希望符合标准，但通常情况并非如此。多缓冲区可能是我们最大的概念之一，它不存在于其他编辑器中。
Nathan: 我从来没有把“固执己见”当成一个值得炫耀的标签。因为我发现固执己见的人往往很烦人。所以我不想成为那种，哦，我们太固执己见了。我们对所有事情都有意见，而且必须按照我们的方式来做。我不想那样。但同时，我也不想成为总是按照老一套方式做事的奴隶。
我想勇于创新，敢于冒险。我不介意有冗余的做事方式。如果人们习惯的某种方式比我们更好的方式更适合他们，我会考虑。但我不认为我会为了满足一些人的偏好而维护一个多缓冲区的替代方案。这是一个相当重要的功能。
所以我认为这是一个具体情况具体分析的问题，但我真的不想把我的做事方式强加于人。我想创新并说，这是我认为一个很好的做事方式，我们对此感到兴奋，但那种排他性或自以为是的气氛，告诉你应该如何编码——我不是那样的人。
但有些事情我认为我们发现很酷，多缓冲区就是其中之一。它们是解决许多编译器错误的好方法。所以我想让人们尝试一下。
我不知道，也许这对于某些人来说是一个危险信号，因为我不够固执己见，但，是的。
Thorsten: 我不这么认为。这只是意味着我们不能指望 Nathan 举办一个关于最佳文本编辑方式的网络研讨会之类的。
Nathan: 我的意思是，我现在甚至都不使用模态绑定了，因为我之前使用了一段时间的 Vim，并且习惯了，但是后来我们写了 Atom，我不得不回到 Emacs 风格的绑定，然后我就再也没有... 是的，我有点忍受了 Vim 的肌肉记忆切换成本，只是为了找回一个我不讨厌的编辑器。
所以，我不知道。我是文本编辑界的忍者大师吗？ 这还不清楚。不是。
Antonio: 但你有两个键盘，而且是 Dvorak 布局，所以听起来很忍者。
Nathan: 是的，没错。是的，我用的是 Dvorak。
Thorsten: 是否有任何三年前你说过 100% 会出现在 Zed 中的东西，但后来你放弃了，因为你意识到这没有意义或者不合适？
Nathan: 没有，但是我们很早就添加了聊天功能，然后意识到，好吧，我们甚至还没有在这个东西里编辑代码。我们这是在干什么？ 所以我们有点，我们为此浪费了几个星期。我只是对协作感到非常兴奋，我不知道，我想探索它，但那时机不对。但现在它回来了，虽然仍然有点不受欢迎，但我看到社区里的人，我看到有人... 是的，Everson 开启了一个 pull request 来改进它，这很酷。所以这是其中一件事。我们还放弃了其他什么吗？
Antonio: 我不这么认为。
Nathan: 是的，还有一些我想从实现中删除的东西。比如我们序列化工作空间的方式，我想让它更简单，但从产品角度来看，目前还没有。
Thorsten: 有意思。
Nathan: 但是我们有很多东西要构建。这就像在你已经快饿死的时候错过一顿饭一样。Thorsten，你有什么想删除的吗？
Thorsten: 删除？ 没有。 我... 我两天前偶然发现了你似乎添加的日记模式，Nathan。我只是在命令栏里输入了 journal，然后我意识到有一个日记模式。然后我看了 git blame，我看到是你添加的。而且，有趣的是，它只有 150 行代码，对吗？ 只是一个用 Rust 编写的文件就完成了所有这些功能。这太酷了。
Nathan: 是的。很好。是的，它不是世界上最好的日记或其他什么。它只是像创建一个新的条目，你知道的，它带有一个时间戳和一个特定的目录结构。它对我来说很有效。我在 Zed 还没有人使用之前就添加了它，因为我需要它。
Thorsten: 我确实认为这很有趣，因为它不占用任何资源。它不需要任何成本。 只是，你可以输入 journal，如果你想要它，你可以得到它。否则它不会伤害你。
Nathan: 但这是一个例子，说明它可能应该是一个扩展，我认为，或者如果它不是一个扩展，我想更努力地去构建一个更完善的 Zed 日记体验。要么两者之一，可能前者，可能在短期内只是把它变成一个扩展。但它并没有造成太大的危害，对吧？它只有 150 行代码，而且... 但是大多数人不知道它。 我们并没有真正宣传它，对吧？是的。
Thorsten: 我觉得更有趣的是这些反复出现的小决定。例如，我们是否在聊天中添加表情符号？或者表情符号反应？所有这些小决定都可能产生巨大的影响。或者协作笔记中的反应，有人可以留下一个赞或者其他什么，或者我们是否显示图片？ Markdown 默认是否呈现或者总是启用？ 我在 pull request 中看到这些问题，我发现这真的很难。 我发现很容易过度思考它们，对吧？ “哦，这是否会将我们带向不同的方向？ 我们应该使用像素化的表情符号吗？ 这是否更符合美学？” 我认为找到一个可以贯穿所有这些决定的原则真的很难。
Nathan: 我同意，如果我说我把这一切都想明白了，并且都记在脑子里，那我就在说谎了。我认为我们都在寻找自己的道路。而且你拥有的代码最终会拥有你。 我只是意识到这一点，就像，当我们添加这些东西时。
每当我们改变构建该事物的地基时，我们现在就必须去访问它并处理它。它只是增加了表面积和质量。所以这是一件事。 然后... 表情符号，听起来不错，除了我们必须维护它并保持它的工作状态。但是这些具体的例子听起来不错，但这似乎是我们必须边走边想的事情。
我想尽可能地扩大范围，具有包容性，并包含许多人的工作流程，而不是成为一个科学怪人。这是一个很难达到的平衡。
但也许我们可以朝着一个方向过度纠正，添加一些东西，然后意识到，我们不能再拥有这个了。把它拿走有点困难，因为现在你有点像从人们那里拿走了一些东西。但是如果你愿意这样做，那么你也愿意承担更多添加东西的风险。
我不想考虑不周。而且我仍然认为 Zed 的某些部分可以更好地与其他部分产生共鸣，并且可以有一个更全面的产品愿景。 虽然我现在想不出任何具体的例子，就是这样。
但我希望它感觉像是一个经过全面思考、精心设计的产品。因此，我们扩展表面积的速度越快，就越具有挑战性。但我愿意达到那个目标，先添加一些东西，然后再集成它。这就是我的想法。我们将看看这最终是否是一个好主意，以及它的效果如何，我们可以进行调整。这就是我现在的想法。
Thorsten: 我们快到时间了。 还有人想补充什么吗？ 比如“Zed 永远不会支持咖啡机——我以我的名义保证”？
Antonio: 只有它是浓缩咖啡机才行。
Thorsten: Zed 中的脚踏板支持。
Nathan: 有一件疯狂的事情有人提出来，我也想过：我们是否可以嵌入特定于平台的浏览器，以便人们可以拉起一个指向他们正在构建的网站的标签页。这是一个例子... Web 技术很慢，所以我不希望引入它。但它确实有用。所以我不知道，我认为这可能非常酷，但我不知道，是的。
Thorsten: 听起来你有一些非常强大的原则，对吧？ 并且由此，其余的都会自然而然地流淌出来。 就像你说的关于扩展一样。 当你说一个扩展只有这么多的时间来做某事时，这意味着很多。 否则，它将被禁用或者我们忽略结果。 因为这已经表明一个价值观是性能，一个价值观是速度、延迟。 我认为，这会波及到系统的其他部分或者社区的其他部分。
Nathan: 对。 我们的北极星是，你不能让你的 Zed 变慢。
因为最终的责任在我们这里。 如果这意味着你不能添加一个功能，因为该功能的作者没有足够的技能或时间或其他任何原因来按时完成任务，那么我宁愿你拥有一个更快、扩展更少的 Zed，而不是让我们陷入一个困境，然后我们就说，哦，好吧，你安装了太多的扩展。 我不希望你陷入这种境地。 所以我希望我们能坚持下去。