对2022年IDE编辑器的看法 - phaazon


作为一名软件工程师，我需要使用工具来解决问题。这些问题是在做项目时的日常小问题：

  • 整理我的工作。
  • 搜索内容，例如文件名、一些文档、发现代码库等。
  • 以高效的方式编辑代码。
  • 构建和运行程序。
  • 测试程序。
  • 调试程序。
  • 对我的代码进行版本控制。
  • 记录笔记、日记、创建会议摘要等。
  • 操纵程序输出。
  • 组成这样的输出。
  • 查看只读数据并对其进行搜索。
  • 通过向目标端点发出 HTTP / gRPC / 任何调用来测试 API。
  • 使用各种系统，如bazel, helm,kubernetes等，并将它们与其他系统组合在一起。
  • 等等等等

无论您使用什么工具，这些问题都大致相同。也许你没有全部，但你每天都会遇到其中的几个。让我们开始讨论大多数人使用的东西：IDE。

IDE集成开发环境
IDE（集成开发环境）是一个为我上面提到的问题的一个子集提供解决方案的软件。
例如，IntelliJ IDEA有一个解决方案：

  • 可以编辑你的代码，进入定义、实现、查找文件、类、符号；
  • 对你的代码进行版本管理并编写Git提交信息；
  • 它有一个调试器；
  • 它有一个构建和测试你的代码的方法；
  • 它有一个终端，你可以随机运行CLI命令；

等等。它并没有解决所有的问题，但显然它解决了其中的一个子集。

对于这样的程序，大多数时候，你安装了它，你就可以不用配置任何东西了。JetBrains编辑器就是因为这个原因而出名的（而且很受欢迎！）。你想用Java工作？安装IDEA吧。当然，你仍然会找到插件来定制体验，但vanilla轻量级编辑器在大多数时候是足够的。

你还有 "可定制的 "IDE：如VS Code。
这种软件通常需要你下载插件，因为默认的体验不太可能支持你的语言，尽管它对大多数人来说应该是足够的。
VS Code显然是最著名的一个，它有一个插件来满足你可能需要（或不知道你需要！）的一切。

我可以将这两个IDE部分合并为一个，但我确实在我的脑海中做出了区别，因为JetBrains是先进的、随时可以使用的；VS Code，无论你是否喜欢它，都是一个重要的软件。微软对它做了很大的改变，因为大多数开发者都会同意它是一个很好的编辑器和开发环境，而且它有助于引入像LSP和DAP这样的东西。你不能以非开玩笑的方式对VS Code说三道四，他们贡献太多，我们都在使用他们的作品。

其余的部分
然后，您进入“做一件事并把它做好”的工作方式，但它比以上谈论的两个IDE更复杂：历史上有Vim、Neovim、git CLI、fzf、终端、shell、TUI 应用程序等工具。
但是，随着时间的推移，出现了一种趋势：人们倾向于将这些“单元工具”转换为 IDE。术语并不重要（无论您想称呼该 IDE 还是您自己的新词）。
重要的是，这些工具不再是最小的，也不再是“做一件事并把它做好”：
例如Neovim，现在更像是一个伪装成编辑器的 Lua 解释器，允许通过插件生态系统构建，而不是一个最小的编辑器。有人告诉我，我错了，以为Lua从一开始就不在其中，所以是的，我从一开始就有点走错路了。

这和这么多年来Vim生态系统中的趋势是一样的。看看vim-fugitive或nerdtree等插件就知道了：
在Neovim中，你有像mason.nvim（这基本上是另一个软件包管理器）、lazy.nvim（同样的东西，但不同）、nvim-tree.lua、一个文件资源管理器、neogit、一个Git在Lua中的实现等插件，还有很多。

所以，是的，我也通过hop.nvim和mind.nvim为这个 "基于插件 "的生态系统做出了贡献，但我一直在思考所有这些问题。这也是我在关于配置与脚本的文章中所讨论的（基本上，我认为配置应该是数据，而不是代码--这正是脚本的意义）。

引用我在Neovim Matrix房间里说过的话，"在人们看到力量的地方，我看到了弱点"。

脚本语言带来了很多强大的东西，例如可扩展性，但它也带来了错误，因此不稳定，而且是一种图灵完备的语言，使主机（即Neovim甚至插件）无法轻松地使用配置来发现选项和数据，这样就没法不参考标准化的API。

这里最让我生气的一点是colorscheme：它们只是脚本而已。其中一些甚至是有状态的（它们在~/.cache/nvim中缓存东西）。所以 "应用一个colorscheme "并不是简单的切换高光贴图：它需要执行代码，这使得对colorscheme的推理变得超级困难。当你知道一个colorscheme可以运行一个HTTP命令时，它又是什么呢？

我已经看到很多新插件，因为我是 This Week in Neovim的作者和维护者。最近，我看到了 TJ DeVries的视频： Effective Neovim: Instant IDE。那个视频证实了我在上面所说的Neovim成为一个 IDE。但这也让我意识到了另一件事；TJ 使用一个插件作为支持来解释如何轻松地将您最喜欢的编辑器变成一个 IDE： kickstart.nvim。

这个插件基本上是一个 Luainit.lua脚本，用作您的配置的启动初始化脚本。你只需安装它，它就会为你下载一堆东西，并调用所有必需的 Lua 代码来正确设置 LSP 实现、Tree-sitter、下载管理器（是的，复数，因为你需要一个用于插件，一个用于 LSP 、调试器、linters 等），安装各种插件以完成、Git 集成、周围对等。然后，我想知道：“新手应该运行一个可以从 Internet 下载几乎任何东西的脚本……或者编写漂亮的它所做的大部分事情——很多——都是靠它们自己做的？！” 问题是，我自己的 Lua 配置，不是基于 kickstart.nvim自从我几年前创建以来，它已经完全过时了，我经常需要返回它来删除或更新内容，尤其是关于 LSP、完成、片段和所有内容。

为什么我觉得不好？
做一件事并把它做好？
与我交谈过的社区的大多数人都不同意我对Neovim的观点。对他们来说，像mason.nvim这样的插件是很了不起的，因为它们缩小了他们的编辑器和他们的编辑器所需的工具之间的差距，使之能够正常工作（Mason下载LSP/linters/DAP适配器/等等）。我也用过Mason，但最终停止了使用，因为它开始下载多年前发布的rust-analyzer的一个版本（那是Mason的一个bug，我猜？）
我得出的结论是，我依赖于一个做HTTP调用的东西来下载工具，而这些工具在理论上可以被我机器上的其他工具使用，而且我自己也可以非常容易地下载。在rust-analyzer的例子中：

rustup component add rust-analyzer

更糟的是......其中一些工具实际上被打包在我的软件包管理器（pacman）中，所以我基本上是在使用一个工具（Mason），它在做与软件包管理器相同的事情。好像我们已经有了足够的软件包管理器一样。

过高和错误的期望
然后我继续思考所有这些插件（其中有些是我使用的，甚至是我创造的，比如Mind！）。我为什么要在Neovim中使用它们？
我从来没有那么喜欢过文件资源管理器，但我知道nvim-tree.lua，而且......为什么我们的编辑器里一定要有这个？
我还记得我写关于Doom Emacs的文章时的心境，它完全改变了我对软件开发的思考方式。

Emacs不属于 "最小的编辑器"，也不直接属于IDE......它是一个独立的野兽，但如果我必须把它与其他东西相比，我不会说VS Code，或Neovim，或其他任何东西。
我会说 "我的终端和我运行的所有命令，包括一个编辑器，一个git实现，等等。"
等一下。为什么我们又要把所有这些功能作为插件推给Neovim？

我没有坚持使用Emacs的原因基本上是因为它的运行时选择，以及最终它的Lisp生态系统。
Emacs社区是我所接触过的最好的社区之一，他们有非常非常有才华的人在研究极其复杂的课题，比如把Elisp代码变成本地代码（通过C），包括Emacs本身。
但是，即使有了所有这些优化，编辑器仍然感觉太慢了，而且有很多背景，你可以感觉到。所有的抽象层，所有的Lisp宏（哦不），等等。

最终，我回到了思考那句话......那句萦绕心头的话...... "做一件事，而且要做对"。
这句话有很多含义，我认为人们一直在撕扯和弯曲它以符合他们的信念，完全无视他们的偏见。
我读到Emacs社区的人说，是的，Emacs仍然适用于这句话，因为 "它只是一个Lisp解释器"。但最终，用户的体验高度依赖于插件，这与Neovim的情况相同。他们必须使用一种图灵完备的语言来配置他们的编辑器，这可能会引入错误和复杂的语句（谁会喜欢通过有条件地导入/要求一个位于你的文件系统中你不知道什么地方的Lua文件来设置一个colorscheme？）

为什么我们又要把所有这些功能作为插件推到Neovim？为什么我不试图专注于使用范围较窄的工具，而是确保工具保持稳定，使用起来功能强大，并与其他部分组成良好？

探索新路径
最近，我发现了Helix，一个“后现代模态编辑器”。
我注意到的第一件事是它在运动方面与Neovim不同：
在Neovim中，在正常模式下，你以一个动词开始，比如删除是d，然后你键入一个动作，比如一个词是w，所以在键盘上键入dw会删除一个词。
在Helix中，它是反过来的。你首先用w选择，然后你应用你想要的动词。所以wd。

起初，我认为这是一个可以忽略不计的差异。然后我意识到 [Helix] 的方法有多强大。
因为你可以 "看到 "选择，你可以先选择，然后决定做什么，或者甚至改变你的想法，扩大一点选择。你有这种很好的视觉反馈。

Helix具有这些包含的功能，需要零配置：

  • LSP 本机实现（编辑器是用 Rust 编写的，那么 LSP 实现也是如此），具有您期望的所有功能，如预览弹出窗口、文档、签名、go-to-def、引用、实现、重命名、代码操作，等等
  • Tree-sitter 支持，包括高亮、缩进、文本对象等。
  • DAP 支持，包括功能和用户界面。
  • 多光标。
  • 环绕括号。
  • Git gutter。
  • 缓冲区、符号、跳转列表、诊断、项目明智/全局 grepping 等的模糊查找器。
  • 等等。

而且它目前还没有插件支持（他们计划在某个时候添加，但目前还没有）。这让我意识到：我在该编辑器中的编辑经验--尽管花了几天时间来调整肌肉记忆--一直是完美无缺的。所以，是的，我怀念我的hop.nvim插件，但我意识到我可以通过使用Kitty提示来解决这个问题，直到那种动机被内置。

然而，我只是在谈论编辑器，在这里。我仍然有按下SPC g g的条件反射，在我的编辑器中弹出Git提示，开始提交......但Helix没有这个。所以我把我的终端分到另一个窗口，使用git CLI。这很好。现在，我想的是，我也许可以投入时间去学习lazygit或其他东西。

关键是，我的编辑器现在又是最小的：我的配置（是公开的，你可以在这里找到）主要是关于bépo的重新映射和一些非常小的美学变化。配置是数据（它只是一个TOML文件），而且我不必再担心稳定性，因为我没有使用任何插件。

事实上，我有一个惊人的编辑体验（甚至更好，说实话，由于先选择后动词的原则，多光标，开箱即用的LSP和Treesitter体验，包括完成度），这正好符合我的要求。

是的，但是
但是有一个问题。看，Helix是关于编辑器的。如果你喜欢在你的编辑器里有一个文件资源管理器，你在无法在Helix中使用它，如果你确实需要，你可能应该使用一个适当的、独立的文件资源管理器，或者考虑其他替代方案，如Neovim。
如果你想在Helix中添加一些东西，你必须打开一个PR，写一些Rust代码。你不能自己去扩展它，因为它没有插件。

对我来说，这已经很好，因为这意味着范围是由Helix团队负责的。
我喜欢这样。我喜欢它，因为它很容易考虑到我的编辑器的功能。这很容易，因为我不必一直担心因为一个插件和我正在运行的编辑器版本之间的不兼容（甚至是两个插件之间的不兼容）而导致某些功能的破坏。

老实说，使用静态和强类型语言（Rust）对我来说比使用Lua这样的语言更有意义。你可以从代码库的所有测试中获益，使用API而不需要在两者之间进行任何ABI转换，并且在编译时捕捉错误而不是等待它们在运行时才爬出来。