Neovim 中文周刊第 3 期

欢迎收看第 3 期 Neovim 中文周刊！

本期周刊包含以下版块：

Neovim 开发近况
- 新功能：摘录近期合并的 PR，以新功能为主
文章推荐
插件推荐

Neovim 开发近况

新功能

perf(lsp): don't construct potentially expensive strings (#32929)

3f788e7 引入的性能回归，关键代码如下

local jsonstr = assert(
  vim.json.encode(payload),
  string.format("Couldn't encode payload '%s'", vim.inspect(payload))
)

#32740 报告在打开非常大的文件的时候 LSP 会造成超过一秒的阻塞延迟，就是因为这里的 assert 的第二个参数在 buffer 很大的时候会构造一个非常大的字符串，构造成本很高。

修复也非常简单粗暴，就是直接把 assert 干掉，因为 vim.json.encode 根本不可能返回一个假值，在传入参数合法的情况下它总是会返回一个字符串，否则会直接 throw 。

PR 作者表示在应用该修改后在极端情况下能获得 10x 性能提升。

feat(runtime): Lua ftplugin sets 'omnifunc', 'foldexpr' (#32697)

默认为 Lua 文件设置

vim.bo.omnifunc = 'v:lua.vim.lua_omnifunc'
vim.wo[0][0].foldexpr = 'v:lua.vim.treesitter.foldexpr()'

其中 vim.lua_omnifunc 提供了 :lua 命令同款补全。PR 作者的想法是可能有笨比配置写炸了，不得不用 nvim --clean 修复的时候，也能获得一个比较基础的 Lua 补全。

feat(defaults): completeopt=popup (#32909)

refactor(lsp)!: rename lsp.completion.trigger() to get() (#32911)

这是一条 BREAKING CHANGE。

纯粹的改名，理由是 trigger 这个词不在 Neovim API 常用的命名规范中，规范详情可查看 :h dev-naming。以前也有不少老 API 因为这个规范改了名，我觉得最经典的就是 disable 被废弃，改用 enable(false)。

build(contrib): add zsh completion (#32617)

为 zsh 添加了 Neovim 的命令行参数补全脚本。目前该脚本还没有添加到 Neovim 的构建系统中，因此不随软件分发，需要包管理器自行安装该脚本。

feat(runtime): Lua ftplugin 'includeexpr' (#32719)

为 Lua 文件新增了 includeexpr 实现，使用了 vim.loader.find，现在 gf 能定位到 rtp 底下的模块了。例如

require("foo^bar") -- ^ 代表光标

在光标处按 gf 能跳转至 rtp 下的 foobar.lua 或 foobar/init.lua 了。效果类似于 LSP 的 Go to Definition，不过作者表示 LSP 能用但是更慢，而且 LuaLS 有时候还抽风定位不了。

feat(float): add winborder option (#31074)

为 Neovim 新增选项 winborder，该选项为 float window 提供默认的边框样式，以减少用户为了保持一致的窗口样式而产生的重复代码。基本上就是把 border 从 nvim_open_win 里拆出来作为一个全局的默认选项，不同之处在于 nvim_open_win 的 border 除了 builtin 的那几个样式以外，还可以传入一个字符串数组自定义样式，而 winborder 目前还不支持自定义样式。

文章推荐

以下内容事实上是 r/neovim 的讨论

Why is neovim still in version 0.xx

Neovim 自 v0.1.0 发布以来将近十年，仍未发布 1.0。

主流观点是 Neovim 团队仍在进行可能破坏向后兼容性的修改，发布 1.0 意味着稳定的 API 保证。不少人表示他们其实不怎么在乎 Neovim 是否 1.0，并且乐见 Neovim 为了更好的发展而做出一些破坏向后兼容性的修改，并质疑不少软件其实根本不算 1.0。还有个恶搞网站 https://0ver.org/ 专门收集了这些长期待在 0.x 版本的软件，Neovim 在里头名列前茅（笑）。

如果您希望了解更多，还可以查看

libghostty instead of libvterm

目前 Neovim 使用 libvterm 提供虚拟终端实现，讨论使用 libghostty 替代 libvterm 的可行性。

不少人认为迁移很可能需要大量工作，但看不到能匹配得上迁移成本的收益，质疑这项提案的合理性。还有一些人则是质疑 ghostty 的可靠性，甚至是厌恶 ghostty，认为 ghostty 只是一次成功的炒作。justinmk 说 Neovim 团队正在考虑替换 libvterm，但他们考虑的替代品是 libvaxis。gpanders 则补充说明 libghostty 的优势在于更加易于维护，由于向 libvterm 上游提交贡献过于困难，Neovim 已经将 libvterm 直接放入仓库中以便自行修改，而 libghostty 的维护更加活跃也更易于向上游贡献。此外，Neovim 团队修改了 libvterm 以提供 Kitty Keyboard Protocol 支持、主题更新通知等功能，而 libghostty 则自带这些功能。gpanders 强调性能倒不是主要考虑的因素，他们并不认为 libvterm 带来了性能瓶颈。

Github Issues 上有一个跟这个话题类似的提案，考虑的是使用 libxev 替换 libuv。类似地，更多人认为迁移的收益远不及成本，Neovim 已经将 libuv 作为 vim.uv 暴露给了用户，迁移需要模拟这些功能，这可能不可行且需要大量的工作。以及大家喜闻乐见的 libxev 目前不支持 Windows（笑）。

插件推荐

minuet-ai.nvim

感谢 anasitacia 投稿推荐，以下内容摘自 anasitacia 的介绍文章。

支持多种 LLM：OpenAI、Claude、Gemini、Codestral、Deepseek, Ollama，以及任何兼容 OpenAI 接口的模型
同时支持 Chat (Instruct) LLM 和 FIM (completion) LLM 两种不同类型的模型
灵活的模版系统来定义 prompt
独立的 throttle 和 debounce 配置，与 nvim-cmp / blink-cmp 的 throttle / debounce 互相独立，保证请求次数不会过于高频
兼容多种前端：包括 nvim-cmp、blink-cmp、built-in completion（需 Neovim 0.11+）、virtual-text 等
可选支持以 In-Process LSP 形式提供补全功能（非默认配置）

nvim-cmp/blink.cmp frontend