Neovim 中文周刊第 1 期

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

本期周刊包含以下版块：

Neovim 开发近况
- 新功能：摘录近期合并的 PR，以新功能为主
- 社区讨论：摘录近期更新的 Issue 讨论，以 Enhancement 为主
文章推荐
插件推荐

Neovim 开发近况

新功能

vim-patch:56957ed: runtime(misc): add support for bzip3 to tar, vimball and gzip plugins (#32684)

feat(lua): better filter private fields from command line completion (#32690)

此 PR 解决了提案 #21660 的第一部分：在 cmdline 补全 vim 时不再将“私有成员”作为候选项。Lua 语言并没有访问级别限制的概念，这里的“私有成员”指的是以下划线 _ 开头的字段。

该 PR 的实现也很 trivial，就是在计算补全候选项时滤掉所有以下划线开头的内容。

feat: add more metadata to _ts_inspect_language() (#32657)

这个主要是利好 vim.treesitter.language.inspect()，新增以下元数据：

metadata：ABI 15 parser 可用，就是一些 parser 的版本信息，没了。
state_count：文档在这里语焉不详，被描述为 "a measure of parser complexity"。
supertypes：ABI 15 parser 可用，同样语焉不详，不是很懂含金量。

clason 锐评 state_count 和 supertypes 是某种“专家知识”，简而言之就是“懂的都懂”。这部分功能应该主要还是利好插件开发者，特别是 treesitter 相关的插件。

feat(comment): allow commentstring to be determined from node metadata (#30501)

这是一个非常实用的功能，用于为一个老生常谈的问题——某些语言根据上下文拥有不同的 comment 规则，比如我们最喜欢的 JSX——提供一个通用的解决方案。现在您可以通过 treesitter query 为捕获的 treesitter 节点设置 commentstring，例如

((jsx_element) @_tag (#set! @_tag bo.commentstring "{/* %s */}"))

简而言之，等到我们最喜欢的插件 nvim-treesitter 足够成熟后，像什么 nvim-ts-context-commentstring 和 ts-comments.nvim 就可以下岗了。

此外，clason 指出也许这个思路不应该局限于 commentstring，还可以推广至其他 option，而 lewis6991 则根据这一提议给出了一些想法，但尚未有更加具体的提案。

vim-patch:08a410f: runtime(vim): recognize <...> strings (and keys) for 'keywordprg' (#32752)

简而言之就是现在 vim 文件里 <cword> 这类 <> 包着的关键词也能按 K 查文档了。Neovim 的脑袋怎么尖尖的（笑）。

feat(lsp): support for resolving code action command (#32704)

为 Neovim 的 LSP 客户端 code action 的 command 属性启用 resolve 功能。

这个 resolve 功能事实上是 LSP 协议提供的一种思路类似于懒加载的机制，正常客户端请求 textDocument/codeAction 后，服务端将计算并返回每个 action 对应的 command 或者 edit，但是当这种计算开销比较大的时候，可以为它们启用 resolveSupport，这样在客户端请求 textDocument/codeAction 时服务端不会做计算，而是直接将各个 action 的 title 作为结果返回，然后当用户选择了其中的一个 action 进行执行时，客户端需要再发送一次 codeAction/resolve 请求，此时服务端才计算出选中的 action 对应的修改并返回。

feat(terminal)!: include cursor position in TermRequest event data (#31609)

这是一条 BREAKING CHANGE。

为 TermRequest 事件提供了终端光标位置的信息。PR 作者提供了以下用途示例

是的孩子们，喜欢 COSPLAY Visual Studio Code 的人有福了！

请注意上述例子只是 PR 作者提供的示例，而不是 builtin 功能。

BREAKING 的部分在于 TermRequest 和 TermResponse 事件接受的数据部分由原来的字符串变更为一个 table。

feat(defaults): jump between :terminal shell prompts with ]]/[[ (#32736)

此功能基于上一条 PR 的功能开发，是同一个作者—— Neovim 的核心开发者 gpanders。需要使用的 shell 支持 OSC 133 才可用。

社区讨论

Google Summer of Code 2025

Neovim 参与了 2025 年的 GSoC。如果您还是一名在校学生，并且愿意参与 Neovim 开发，请查看 Google Summer of Code。

如果您不了解 GSoC，GSoC（Google Summer of Code）是由 Google 举办的面向学生的开源活动，学生选择心仪的开源项目并提交提案，通过选拔后在导师的指导下完成提案，成功结项者可获得 Google 提供的奖金。

感谢 Krysztal Huang 指正，GSoC 并不要求一定是学生，也可以是成年的开源初学者，详情可参见 FAQ。

presentation mode (#31825)

乍看这个标题我还以为是类似 present.nvim 那种为 markdown 等格式添加幻灯片播放的功能，前段时间 tjdevries 的 Advent of Neovim 系列带着大伙做了这个，导致那段时间 Github 上一堆 present.nvim ……

仔细看了一下这个提案的目标应该是为 markdown、LaTex 这些格式提供一种渲染视图，目前 Neovim 的视觉呈现这块主要还是 conceal 在撑着，justinmk 的意思是在 Normal 模式下 Neovim 为了能正常编辑而没办法渲染得很 fancy，而在新引入的 presentation mode 中我们可以尽最大努力提供一个足够美观的视图而无须考虑编辑。就类似于 Visual Studio Code 的预览窗口，道理差不多。

可能最终希望呈现的效果是类似于 markview.nvim，该插件为 markdown 等格式基于 conceal 和 extmark 提供了一个非常 fancy 的预览模式。喜欢这个插件的读者还可以尝试一下同作者写的 helpview.nvim，该插件为帮助文档提供了更 fancy 的渲染风格。我个人用了这些插件一段时间，最近切回了 render-markdown.nvim，主要原因在于 markview.nvim 对我来说实在有点过于 fancy 以至 noisy 了。

目前该提案尚未拥有 owner，此外该提案打了 gsoc 的标签，对此感兴趣的开发者可以关注一下。

该 Issue 是一个任务追踪列表。justinmk 强调 Neovim 目前还不打算集成 AI 功能，但是他确实在关注这个领域，并希望为 AI 相关插件提供一些可供使用的基础功能，这些缺席的基础功能通常被各个插件重复实现，这对更多非 AI 插件同样有用。

我挑一些当前该提案追踪的一些提案简单介绍一下，

改进 prompt buffer，就是平常 telescope.nvim 等插件用来输入的那块 buffer
- 支持输入多行 (#32420)
- 支持从 register 中粘贴内容 (#32661)
vim.ui.progress 进度条显示 (#32537)
- statusline 默认显示 LSP 进度 (#28809)
vim.ui.open_win 提供一个更加易用的创建 Window 的 API (#25514)

同样，该提案打了 gsoc 的标签，对此感兴趣的开发者可以关注一下。

image API (#30889)

支持显示图片！

clason 认为当前应该专注于推动实现 kitty 图形协议支持，理由是该协议是最流行的终端图形协议。但不少人持不同意见，fredizzimo 指出 kitty 图形协议仅在 TUI 中可用，这不利于 GUI 等实现图形支持，他提议抽象为使用 extmark 标记图片，然后 TUI 和 GUI 可以各自实现如何渲染 extmark。schrmh 则质疑 clason 关于“kitty 图形协议是最流行的终端图形协议”的观点。

我的理解是 clason 认为 kitty 图形协议已经是某种事实标准，Neovim 应该优先支持解析并渲染该协议以便支持大多数终端，并且有点想把该协议作为 Neovim 的“标准图形协议”的意思，GUI 实现不应该再提出某种新的图形协议，而是通过支持 kitty 图形协议来支持图形渲染。而 fredizzimo 等人的意见则刚好相反，他们认为强依赖于某种特定协议是非常危险的行为。

截止至目前，chipsenkbeil 已经为该提案发起了 PR，正在接受 review。此外，在图片渲染支持进入 Neovim 之前，您可以先行通过插件尝鲜，目前实现最丰富的插件应该是我们所有人都最敬爱的 folke 佬的 snacks.nvim，详情参见官方文档。

文章推荐

Neovim’s Future Could Have AI and Brain-Computer Interfaces

这是一篇报导，总结了一下 Neovim 核心维护者 justinmk 在 Neovimconf 2024 上的演讲 State of Neovim 2024 的内容，值得一看，毕竟我不是很喜欢看视频（汗）。

主要聚焦的是 justinmk 作为核心维护者对 Neovim 未来发展趋势的见解和目标，某种意义上这代表了 Neovim 开发团队的视角

脑机接口。justinmk 认为脑机接口将在十年为单位的未来里开始流行，他认为在拥有脑机接口的未来，“按钮和菜单将比键盘驱动的交互设计更容易被淘汰”。高情商——我只能说 justinmk 确实是高瞻远瞩，连脑机接口都考虑上了。
我们所有人都最喜欢的 AI。justinmk 强调自己 "excited about AI"，顺嘴夸了一波 Neovim 的文档写得太好了啊，AI 生成 Neovim 内容都嘎嘎好。那 AI 啥时候集成进 Neovim 捏？不好意思，还在考虑。
还有更多内容敬请阅读原文。

感兴趣的还可以看看 Prepare for version 1.0，讲了 Neovim 在 1.0 以前至少需要完成哪些“小”目标。