这是我与 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 或其他工具，获得了所有这些强大的功能，但却因为延迟而感到非常沮丧。
所以这总是一个权衡。我的梦想一直是两者兼得，拥有一个功能强大但又简洁、外观极简且速度超快的工具。超快的速度和这种强大的功能很难结合。
我的职业生涯大部分时间都在努力实现将它们结合起来。但这就是目标。
但我总是希望在用户体验上倾向于极简主义，我用的类比是特斯拉 Model S。你走上前去，门把手会从侧面弹出。在不需要时或会产生阻力时，它会收起来，但在恰到好处的时刻可用。这就是梦想。
Thorsten：性能尽可能好，功能尽可能多，但不能以牺牲性能、极简主义或臃肿为代价。
Nathan：是的，不能以牺牲速度和噪音为代价。让我的代码居中，并且不要在我试图实现的基本操作（即编辑代码）之间引入延迟。这种基本体验必须快速，无论如何。
Antonio：我学的第一门编程语言是 C#。我以前是 Windows 用户。所以我记得打开 Visual Studio，不是 Visual Studio Code，而是原版的 Visual Studio，它们有一个加载画面，因为启动时间太慢了。那大概是 Visual Studio 2005，加载 DLL 一、二、三等等。
和 Nathan 一样，从那个到之后我用的 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 中我仍然喜欢的一个用户体验功能，尽管它不会让我使用它们，是重命名变量的操作。在 IntelliJ 中，它会高亮显示所有出现的变量，就像你在其他地方实时编辑名称一样。我记得当我们实现 Zed 中的重命名功能时，脑海中就是这样做的。这是他们通过所有内置语言分析所做的一件非常酷的事情，我们也探索了这样做。
我们确实将 tree-sitter 的语法感知与可以发送到语言服务器的重命名调用结合起来。在大多数情况下，这非常好，能满足你的需求。它还不能让我们做 IDE 所做的所有花哨的事情，但也许 tree-sitter 和语言服务器可以扩展其功能，让我们能够更好地完成这些事情。
Thorsten：假设性能不是问题，并且，用 Nathan 的类比，所有东西都可以收起来。那么，有没有什么你永远不会添加到 Zed 的 IDE 功能，因为你认为它不适合这里？例如：“这不是 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 项目或什么的，所有操作都通过点击完成。那种我不要。
我不想用按钮取代命令行体验。像那样我觉得没什么大不了的。我喜欢与机器保持近距离，并用语言与机器交流。我希望 IDE 能够感知终端和命令行的存在，并与它们干净地集成，避免我们试图在视觉范式中定义一切的状态。作为 Unix 哲学和补充的自然产物，我认为这更符合我的速度。
但是，如果我能按一个快捷键而不是切换到终端，按向上箭头然后按回车来运行测试（这是Kirill 和 Piotr 正在做的工作）？我会接受，但我不想它隐藏着只是运行一个命令的事实。
Thorsten：这是一个很好的区别。这可能也是我将 IDE 与之关联的一点：你只是启动它，然后点击那个绿色的播放按钮，你不知道发生了什么，但有人告诉你这是运行它的方式。然后当出了问题时，你不知道到底发生了什么。
Nathan：我喜欢那种骨感（bare bones）的感觉，但在其中保持高效。我不想有魔法。
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，可以说很多，你知道，我当然可以说很多关于 macOS API 的事情——有时与它们交互简直是噩梦——但想想 iPhone 和 iPhone 上的应用程序：你无法在主屏幕上搞乱基本体验，对吧？我真的很喜欢这一点。你有很多灵活性，对吧？但它是在不会降低整体体验的地方。
所以就像 Nathan 说的那样，这不仅需要工程方面的努力，我认为也需要用户体验方面的努力，来理解那些扩展点是什么，那些接口是什么，以及在哪里插入它们。但我喜欢用苹果的方式来做。
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。我希望能把音量调到 11，但也许它在第四年而不是第一年达到 11，我们会在保持其他价值观不变的情况下逐步实现。
Thorsten：我不知道我为什么总是在这些轴线方面思考，但是：自带电池 vs. 什么都没有。现在 Zed 理解很多语言，理解很多语言服务器。人们甚至会指出这一点，他们会说：“太棒了。我第一次打开 Zed，在我的 TypeScript 项目中，它立刻就自动完成了。”你认为这有极限吗？是否存在一个核心的自带电池子集，但不能超过八个电池，十个电池就有点太多了。剩下的呢？你必须使用扩展。而且我还认为这里的难点可能是每个人都需要不同的电池，对吧，无论他们正在做什么。你对此有什么看法？
Antonio：对我来说，每当我们在编辑器中包含某些东西时，我感觉我们都在承诺它会以某种方式工作。基本上，核心的分类是我们能够坚持的，我们可以向用户兑现承诺的东西。其他的，我不知道。就像你说的，每个人都需要不同类型的电池，是的，我不确定在哪里划清界限。
Nathan：但我认为这就是你划线的地方。我们想要壮大我们的团队，但即使我们壮大了团队，我们的团队也无法涵盖所有事情，这是人力所不能及的。但我们有可能涵盖很多。归根结底，人们只是想要一个按他们想要的方式工作的编辑器。我猜有一部分人真的很喜欢，你知道，用木头制作自己的键盘，自己焊接，然后定制他们的编辑器。
他们只是想要一个编辑器工具包，然后把它们组合在一起。但我认为绝大多数人，包括我自己在内，如果他们只是打开它就能工作，会更开心。
我们正在努力寻找正确的平衡。我认为我们把很多语言都纳入了核心，因为我们还没有完全准备好可扩展性。其中一些将会被剥离出去，因为如果由我们以外的人来维护，那体验质量会更高。所以归根结底就是这样。我想 Antonio，你已经说过了。我们会努力，但我们可能会不时出错，比如忘记将语言服务器更新到最新版本，或者我们没有使用正确的版本。但我认为这是正确的态度。如果它在核心中，那么它就应该很好。我们会维护它。我们的人手有限，一天的时间也有限。
Thorsten：你八周前就有这种看法了吗？还是 Zed 开源并涌入所有问题和拉取请求后才形成的？
Nathan：哦，我们知道会这样。我确实知道，是的。这就是为什么可扩展性在路线图上排名相当靠前，因为，还有 Linux，两者都是，因为它们都有些……我们知道人们会想让它在 Linux 上运行，无论我们喜欢与否，或者当时是否安排了，人们都会尝试在这方面做出贡献。所以我们想对此持开放态度。然后我们知道人们会尝试贡献一些……
Jason Rudolph，他以前和我们一起在 Atom 工作，他说开源贡献有时就像有人送你一只免费的小狗。
因此，现在安排可扩展性是非常慎重的。我们知道我们不想延迟开源，让这些东西准备好，但我们也知道很快就需要一个“泄压阀”，用于我们无法领养的免费小狗。
Antonio：我想补充一点，这并不是说如果某样东西在核心中，它就不是一个开源项目。人们仍然可以帮助我们维护，提高其质量。只是入门门槛会高一些。我们会对维护核心中任何东西的特定质量负更多责任。
Thorsten：这听起来没有那么有争议，但我们都曾参与过一个将按键绑定从 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：有没有什么你三年前曾百分百确定会加入 Zed，但后来发现它没有意义或不适合，所以放弃了？
Nathan：没有，但我们很早就添加了聊天功能，然后意识到，好吧，我们甚至还没有在这上面编辑呢。我们在做什么？所以我们有点，我们为此浪费了几周时间。我只是对协作感到非常兴奋，我不知道，我想探索它，但当时时机不对。但现在它又回来了，虽然仍然有点被冷落，但我看到社区里有人……是的，Everson 打开了一个改进它的拉取请求，这很酷。所以这是一件事。我们还放弃了其他什么吗？
Antonio：我不认为有。
Nathan：是的，我仍然想从实现中删除一些东西。比如我们序列化工作区的方式，我希望它更简单，但到目前为止，从产品角度来看，没有。
Thorsten：有意思。
Nathan：但我们有太多要构建的。这就像当你已经快饿死了，却还跳过一顿饭。Thorsten，你有什么想删除的吗？
Thorsten：删除？没有。我……我两天前偶然发现了你显然添加的日记模式，Nathan。我只是在命令栏里输入了 journal，然后我意识到有日记模式。然后我查看了 git blame，我看到是你添加的。而且，有趣的是，那只有 150 行，对吧？这是一个用 Rust 完成所有这些功能的文件。那真的很酷。
Nathan：是的。不错。是的，它不像世界上最好的日记功能或什么。它只是像创建一个新条目，你知道，它有一个带时间戳的目录结构，以某种方式。它对我有效。我是在 Zed 甚至还没有人使用之前添加的，只是因为我需要它，是的。
Thorsten：我确实认为这很有趣，因为它没有任何占用。它不花费任何东西。你只要输入 journal 就可以得到它，如果你想要的话。否则它不会伤害你。
Nathan：但这只是一个例子，我认为在某个时候，它应该是一个扩展，或者如果它不是一个扩展，我会更努力地去实现它，真正将一个更完整的日记体验构建到 Zed 中。两者之一，可能更倾向于前者，短期内可能只是把它变成一个扩展。但它并没有造成那么大的伤害，对吧？它只有 150 行代码，而且……但大多数人不知道它。我们并没有真正宣传它，对吧？是的。
Thorsten：我觉得有趣的是这些不断出现的小决定。例如，我们是否在聊天中添加表情符号？或者表情反应？所有这些小决定都可能产生巨大的影响。或者在协作笔记中的反应，有人可以点赞或什么的，或者我们是否显示图片？Markdown 默认渲染还是始终启用？我看到这些问题在拉取请求中出现，我觉得真的很难。我觉得很容易想太多，对吧？“哦，这会把我们引向不同的方向吗？我们应该有像素化的表情符号吗？这更符合美学吗？”我认为找到一个可以贯穿所有这些决策的原则真的很难。
Nathan：我同意，如果我说我把所有事情都想明白了，都记在脑子里，那我就是在撒谎。我想我们都在摸索。你拥有的代码最终会拥有你。我只是意识到这一点，因为我们添加了这些东西。
每当我们改变构建该事物的基础时，我们现在都必须去处理它。它只是增加了表面积和质量。所以这是一件事。然后……表情符号，这对我来说听起来不错，除了我们必须维护它并使其正常工作。但这些具体的例子听起来不错，但这似乎是我们必须边走边想办法解决的问题。
我想我希望尽可能包容，并接纳很多人的工作流程，同时又不成为一个“科学怪人”。这是一个很难掌握的平衡。
但也许我们可以朝一个方向过度矫正，添加一些东西，然后意识到，我们不能再拥有这个了。要把它拿走有点困难，因为现在就像你从人们手中拿走了一些东西。但如果你愿意这样做，那么你也就愿意在你添加的东西中承担更多风险。
我不想思虑不周。而且我仍然认为 Zed 的某些部分可以更好地与 Zed 的其他部分产生共鸣，并且可以有一个更全面的产品愿景。尽管我现在想不出任何具体的例子，所以就这样吧。
但我希望它感觉像一个整体思考，精心设计的产品。所以我们扩展表面积越多，速度越快，挑战就越大。但我愿意逐步实现它，添加东西然后整合。这就是我的想法。我们会看看这是否是一个好主意，以及如何运作，我们可以进行调整。这就是我现在正在思考的。
Thorsten：时间快到了。还有人想补充什么吗？比如“Zed 永远不会支持咖啡机——我以我的名字保证”？
Antonio：除非是意式咖啡机。
Thorsten：Zed 支持脚踏板。
Nathan：有人提出了一个疯狂的想法，我也想过：我们能不能嵌入特定平台的浏览器，这样人们就可以打开一个指向他们正在构建的网站的标签页。这是一个例子……Web 技术很慢，所以我不想把它引入。但它确实有用。所以我不知道，我认为这可能相当酷，但我不知道，是的。
Thorsten：听起来你有很多坚定的原则，对吗？然后其他的都由此而来。就像你说的扩展。当你说一个扩展只有这么多时间来做某事时，这说明了很多。否则，它就会被禁用，或者我们忽略结果。因为这已经说明一个价值是性能，一个价值是速度，延迟。我认为，这会影响到系统的其余部分或社区的其余部分。
Nathan：没错。我们的北极星是，你不能让你的 Zed 变慢。
因为最终责任在我们。如果这意味着你不能添加某个功能，因为该功能的作者没有技能或时间等等来完成任务，那么我宁愿你拥有一个更快的 Zed，拥有更少的扩展，也不愿我们陷入困境，然后我们说，哦，你安装了太多的扩展。我不想让你陷入那种状态。所以我希望我们能坚持下去。