Vim 和 Neovim 编辑器在世界各地广受开发人员和文字编辑者的欢迎和喜爱,我也一样。
在由 Bram Moolenaar 领导 Vim 开发的过程中,一直存在一种趋势,即用户希望通过提供各种插件的方式将 Vim 变成一个 IDE:文件资源管理器、UI 组件和图标、代码补全、诊断、代码格式化等等。Vim 使用了 vimscript 作为其一等公民来进行支持,但这其实是非常小众的,并且阻碍了人们创建自己的插件、或给 Vim 项目本身提交代码(当然也和 vimscript 自己的文档和语法设计有关)。Vim 的可扩展性和用户需求之间的冲突一直在增加。
随后 Neovim 于 2014 年问世。为了提供更丰富友好的功能,以及更接近 IDE 的编辑体验,它引入了 lua 作为脚本语言, LuaJIT 作为运行时解析器。这在一开始引起了很大争议,因为 lua 既带来了不兼容 vimscript 的破坏性更新( vimscript 作为专门为 Vim 设计的脚本语言,确实更能融入编辑器中),又不像 python 或 javascript/typescript 那么受开发者欢迎。在 Neovim 和 lua 出现之前,Vim 社区通常利用这些外部语言来实现复杂的插件,例如自动补全、文件资源管理器等。但是,编辑器本身和语言解释器/运行时之间的 IPC 开销无法消除,额外增加一个语言也无法开箱即用。
事实证明 Neovim 的选择是成功的,luajit 大大提高了性能,而 lua 提供了更好的语法(与 vimscript 相比)来处理用户自己的逻辑。这鼓励了更多用户创建自己的插件(包括我自己),以及给 Neovim 项目提交代码。与此同时,Vim 带来了 vimscript9 作为替换原 vimscript 的更好的脚本语言,但这仍需要付出很多努力,包括开发/维护以及时间和用户反馈。显然,嵌入一个现成的脚本语言要容易得多,也快得多。
脚本在 (Neo)Vim 编辑器中扮演着一个最为重要的角色:它驱动着编辑器的外观和行为、调度着后台任务、负责与远程进程通信、等等。与此同时,它也将编辑器变成一个语言解释器/运行时/虚拟机。当我们将 (Neo)Vim 编辑器看作一个语言解释器时,我们会开始思考更多的方面:
选择 lua 的劣势逐渐显现出来,毕竟它受限于自己糟糕的语法设计,也缺乏庞大的社区支持,远远落后于上述这些真正流行的脚本语言。
这就是为什么在审视( Neo ) Vim 编辑器时,突然会冒出用 Rust+Javascript 重写(重新发明)它的想法。与 c/c++相比,rust 提供了如此多强大而高效的语言特性,更别提它的工具链和活跃的社区。至于脚本,我们希望有一个包含以下特点的脚本语言:
其实我们没有太多选择:
Javascript 满足了大部分的要求,谷歌在 V8 引擎上花费了数百万美元和不计其数的开发时间,社区也出现了 QuickJS,两者都是非常好的内置入编辑器的解决方案。但是等等,js 的语法糟糕且混乱,它的成功实际上属于浏览器和网络行业,并非 js 本身。所以最终的目标是用 typescript 编写脚本,js 则可以扮演一个中间层的角色。ts 弥补了 js 的一些缺点:
另一个强劲趋势是:越来越多的 (Neo)Vim 插件通过定制 floating window 和 buffers 来提供复杂的 UI 部件。甚至还出现了一些 TUI 库/框架,它们将 (Neo)Vim 视作一个包含着 UI 部件的屏幕。这个想法引导我们看向一些现代的 GUI 框架甚至 Web UI 组件,例如 Qt、Tk/Tkinter、Material UI、Iced。
大多数 GUI 框架都支持以下功能:
通过引入具有此类概念的 TUI 引擎,可以改善视觉效果、标准化小部件行为并减少插件开发工作量。
1
linrongbin OP 上一个帖子 ( https://www.v2ex.com/t/1070051 ) 直接转发了知乎的链接,导致风评很差,这里再复制粘贴一份吧。
|
2
Kaiv2 64 天前 1
很不错,看看是否会发展起来
|
3
Yjhenan 64 天前
大有可为
|
4
GenshinMinecraft 55 天前
前几天才在 Rust tg group 遇到 rsvim 开发者
|
5
linrongbin OP @GenshinMinecraft 退了好几天啦
|