我的 Vim 自动补全配置变迁史

[reorx]

原文: https://reorx.com/blog/the-history-of-my-vim-completion-config/

---

Vim 是我系统学习的第一个终端编辑器，从学生时代至今，我几乎每天都会使用到它（长时间写前端代码时除外）。

自动补全（ auto completion ）大概是每个 Vim 用户在掌握了基本用法后，第一个想要进阶配置的功能。这篇文章记录了从 2017 年至今，我的 Vim 自动补全配置的每次变更，从中窥见 Vim 生态发展的一角，也纪念这些曾经给我带来过便利，最终在技术发展中被轮替的插件。

Before 2017

2017 年我从 Vim 切换到 Neovim（下文简称 nvim ），除了增加 nvim 特殊的 init.vim，基本沿用了以往的配置和插件。

彼时我使用的语言以 Python 为主，自动补全插件为 jedi-vim。

我对 jedi-vim 的了解最早可以追溯到 2012 年，那时还没有 LSP 的概念。开发者们针对自己的需求，编写如语法增强、文档查看、自动补全等各类插件，非常零散。jedi-vim 对这些插件的功能进行了重构和集成，提供了开箱即用的统一解决方案，一经推出便广受好评，成为使用 Vim 进行 Python 开发的标配。在后来的十年里，它的初心始终不变，得到持续的维护并沿用至今。

2017

还是 2017 年，在切换到 nvim 后不久，我发现了 deoplete 插件，经过一番尝试将 jedi-vim 替换成了 deoplete + deoplete-jedi 。

Commit: 0760ba6f7d11526e38e15b36a0d1db8709834825

use deoplete, remove jedi-vim

committed on Jun 28, 2017

-Plug 'davidhalter/jedi-vim', { 'for': 'python' }
+Plug 'Shougo/deoplete.nvim', { 'do': ':UpdateRemotePlugins' }
+Plug 'zchee/deoplete-jedi', { 'for': 'python' }

deoplete 的目标是提供一个通用的异步自动补全框架，这在设计理念上是一个巨大的进步。jedi-vim 虽然开箱即用，但却是一堆粘合在一起的 spaghetti code ，不仅随着项目功能的增加变得越发庞大和迟缓（这是我想要离开 jedi-vim 的主要原因，文件一大各种操作都变得肉眼可见的慢），代码的可读性也非常糟糕，难以维护和参与。而 deoplete 本身并不提供针对任何语言的分析能力，只专注于与 nvim 的整合和 completion source 的调度，并且利用 nvim 的异步功能（后来 vim 8 也推出了自己的 async 接口），大大提升了补全的流畅度。

但 deoplete 也有着自身的局限性。首先配置变得复杂且麻烦，用户得理解其架构和设计，学会如何通过 deoplete 对接编程语言的 completion source 。为了使检查结果的提示贴合自己的使用习惯，还要再去学习 completion source 的配置，每个语言的实现不同，配置也不一样。

当时我却没有料到，配置复杂的问题在 LSP 时代不仅没能得到解决，反而变本加厉，直到本文完成时也依旧是使用者的巨大痛点

deoplete 的第二个问题是，它只专注在 completion ，缺少对于 go to definition 和显示 function siguature 等功能的支持，这对于从 jedi-vim 的 all-in-one 体验切换过来的我，显然是个巨大的落差。好在我找到了其他插件来解决这些问题。

对于 “go to definition”，通过装回 jedi-vim 并打开无补全模式可以解决。这样既可以使用 jedi 提供的 go to definition 等辅助功能，也不会与 deoplete 的补全产生冲突。

Plug 'davidhalter/jedi-vim', { 'for': 'python' }

" jedi (only for go to definition)
let g:jedi#completions_enabled = 0

对于 “function signature”，我找到了 deoplete 作者的另一个插件 echodoc 来实现。它将函数的签名信息显示在 cmd 区域，规避了 deoplete 占用 completeopt 导致编辑界面无法显示补全菜单以外的其他信息的问题。

Plug 'Shougo/echodoc.vim'

" echodoc
set noshowmode
let g:echodoc#enable_at_startup=1

2018

2018 年是里程碑式的一年，Language Server Protocol 的生态逐渐成熟，新的补全工具涌现。我对 LSP 感到相当兴奋和好奇，迫不及待地从 deoplete 更换到了对 LSP 有更好支持的 ncm2。

Commit: 7a1442c2334673ac17162c101663e220ef43a3c8

nvim: update completion plugins (a lot!)

• move and reorg completion plugins definitions and configurations
• use LSP completion instead of deoplete
• remove eslint from ale_linters
• enable virtualenv display for airline
• still working on passing settings to pyls through LanguageClient-neovim

committed on Dec 7, 2018

-Plug 'Shougo/deoplete.nvim', { 'do': ':UpdateRemotePlugins' }
-Plug 'zchee/deoplete-jedi', { 'for': 'python' }
+Plug 'ervandew/supertab'
+Plug 'ncm2/ncm2'
+Plug 'roxma/nvim-yarp'
+Plug 'autozimu/LanguageClient-neovim', { 'branch': 'next', 'do': 'bash install.sh', }

从设计理念上看，ncm2 与 deoplete 并无差别，都是通用的异步自动补全框架，唯有与静态分析器的集成方式不同，deoplete 是自己的私有协议，ncm2 则拥抱了更加通用的业界标准 LSP 。

我为 deoplete 的作者感到惋惜，他在 LSP 还不够成熟的时期，自己设计了与静态分析器的集成协议，构建了一个完整的补全插件生态[^1]。还写了很多小巧实用的插件，代码也非常优美，让人感到赏心悦目。但因为 LSP 的发展和新一代更加 LSP native 的补全插件的涌现，它已不再是当下的第一选择，势必因为历史包袱而逐渐被淘汰。

说回 ncm2 ，其实它也有许多瑕疵，印象中配置过程比 deoplete 还要痛苦，但当时已经是让 nvim 用上 LSP 的最好插件了。之后我对 JetBrains 和 VSCode 的使用频率变高，疏于对 nvim 插件的持续跟进，ncm2 于是一直服役到 2021 年。

ncm2 出现后没过多久，coc 也诞生了，在 2019 年成为最受人关注的 vim 补全插件，国内也看到很多文章（似乎作者就是国内开发者）。当时我简单了解后因为它是 nodejs 实现的，就放弃了尝试的念头。开玩笑，jedi 这么一大坨 Python 就慢成这样，nodejs 岂不是更糟糕吗。没想到 coc 一直流行到现在，这似乎再次证明了一个论点，即易用和功能全面才是软件流行的第一因素，无论它的实现有多么不优雅、效率有多么低，只要是能用的、可接受的就行，用户在使用体验上得到满足后，对于小问题的容忍度是相当高的。

2021

2021 年的某一天，因为 ncm2 长期存在的一个小问题（现在已经忘了），我一气之下再次打开了 deoplete 的项目页面，惊喜地发现它已经完善了对 LSP 的支持，于是立刻就开始迁移，换回了我更欣赏且代码品质更胜一筹的 deoplete 。

Commit: cd044fcda603ad5b9ee16bd4d7d7873c9ade9a31

nvim: rework on languageserver & python completion

committed on Mar 26, 2021

-Plug 'ervandew/supertab'
-Plug 'ncm2/ncm2'
-Plug 'roxma/nvim-yarp'
-Plug 'autozimu/LanguageClient-neovim', { 'branch': 'next', 'do': 'bash install.sh',
+Plug 'Shougo/deoplete.nvim', { 'do': ':UpdateRemotePlugins' }
+Plug 'prabirshrestha/vim-lsp'
+Plug 'mattn/vim-lsp-settings'
+Plug 'lighttiger2505/deoplete-vim-lsp'

这次变更除了换回 deoplete ，还去掉了陪伴多年的 supertab ，在抄了一段看不懂的配置后，实现了我更为习惯的 tab 键触发补全的方式。

2022

在咖啡馆结束了一天的主要工作后，看着好友 @iwendellsun 流畅的 vim 操作，我问起了它的 nvim 自动补全配置，果然有许多我从未听过的东西。于是趁此机会赶紧向他请教，在他的指导下完成了 2022 年的配置升级。

Commit: 3de43d030ca40b498911c6752a7396af38202fe6

nvim: use nvim-cmp for completion

committed on May 08, 2022

-Plug 'Shougo/deoplete.nvim', { 'do': ':UpdateRemotePlugins' }
-Plug 'prabirshrestha/vim-lsp'
-Plug 'mattn/vim-lsp-settings'
-Plug 'lighttiger2505/deoplete-vim-lsp'
-Plug 'w0rp/ale'
-Plug 'rhysd/vim-lsp-ale'
+Plug 'williamboman/nvim-lsp-installer'
+Plug 'neovim/nvim-lspconfig'
+Plug 'hrsh7th/cmp-nvim-lsp'
+Plug 'hrsh7th/cmp-buffer'
+Plug 'hrsh7th/cmp-path'
+Plug 'hrsh7th/cmp-cmdline'
+Plug 'hrsh7th/nvim-cmp'

这次变更分以下几个方面：

1. 补全框架从 deoplete 变为 nvim-cmp，我还没细看，不过据说它就是现在的 meta & state of the art.
2. LSP 集成从 vim-lsp 换成了 nvim-lspconfig 。迟来的官方出品。
3. 去掉了 ale 和 vim-lsp-ale 。nvim-cmp 可以将 LSP client 返回的错误提示直接在行内显示，不需要再依赖 ALE 这个 linter 框架了。
4. Last but not least, 这些插件的配置语法几乎都是用 Lua 写的，这让用了 10 年 Vimscript 的我感到极度陌生和恐慌。

相比之前的变更，这是唯一一次生搬硬套而非全部理解的，这次我主要是想快速上车，免得被社区发展抛在了后面，现在实在没有太多精力可以悠闲地慢慢尝试。虽然有人指导免去了初次上手的痛苦，但可以预见的是，想要让这套插件和我的编程习惯完美契合，还有许多坑等着我去折腾呢。

参考链接:

• Setup | nvim-cmp
  • List of sources · hrsh7th/nvim-cmp Wiki
  • Example mappings · hrsh7th/nvim-cmp Wiki
• Default configuration | nvim-lsp-installer
• Server Configurations | nvim-lspconfig
  • pylsp
  • pyright
  • gopls
• ray-x/lsp_signature.nvim: LSP signature hint as you type

参考配置:

• https://github.com/xwjdsh/dotfiles/blob/master/nvim1/lua/plugins.lua
• https://github.com/Avimitin/nvim/blob/master/lua/plugins/load.lua

结语

Vim 的 LSP 插件生态还有许多有待优化的空间，开发者们对生产力的追求是永无止境的，下一个 5 年编辑器的体验会有着怎样激动人心的变化，我对此充满期待。

[Leviathann]

jedi 这么一大坨 Python 就慢成这样，nodejs 岂不是更糟糕吗

这个更糟是怎么来的
python 从来都是性能洼地啊
跟 js/ts 没法比

[neilyoone]

哈哈哈, 程序员里 vim 用户可不多

运维用的多 还差不多

[Lionad]

现在真的是没空折腾编辑器。用 vscode 还是方便很多。vim 只用 basic config 当个 terminal 纯文本编辑器。
同样的，操作系统也是这样。之前折腾 archlinux ，现在发现还是无脑 macos 或者 windows

[0o0O0o0O0o]

捉虫

> 我问起了它的 nvim 自动补全配置

[Maboroshii]

最初学习 vim 的时候用 ycm ，后来发现 coc.nvim 很香就一直用了，coc 感觉是个挺复杂的东西，我也没怎么学，就最简单的配置一直在用

[youshangdemajia]

这种开源软件搭积木的效率和效果比起靠东欧便宜劳动力肝出来的 JetBrains 系 IDE 还是差太多了。
我用 VIM 的键位足矣，个人认为这是最有价值的。

[reorx]

@Leviathann 也是，nodejs 做服务端性能不差，我应该是长期使用 webpack 导致的 nodejs 恐惧症

[reorx]

@youshangdemajia 握手，是的，我有个精简版的单文件配置，专门给 VPS 用

[Buges]

node 实现应该与复用 vscode 相关 lsp 的生态有关。
vim 一直都当 np++同类的记事本用，除了基本的语法高亮和简单词汇补全就不多配了，之前试过 https://github.com/AstroNvim/AstroNvim 但主题不能自适应终端亮色 /暗色，再加上体验终归不如 vscode （以 Python 为例，微软的 pylance language server 只许可 vscode 用，开源的 pyright 只管类型，缺乏不少信息）

[ViriF]

nvim 的 virtual text 和 virtual line 目前还是尴尬了一丢丢，导致 inlay hints 目前不能像 idea 和 vs(c)系编辑器一样到位显示；另外就是个人感觉 nvim 插件环境还是挺不稳定的，最近几个月经常能看到 cmp 、lsp/installer 、tele 啥的提示 breaking changes ，虽然有更新就是好事，太频繁了我还是不免有点烦躁

[stevenshuang]

借楼问个问题，之前也在尝试 coc.vim ，只要写 go ，配置 gopls 后，打开项目会启动 4 个 gopls 的进程，但是我之前用 youcompleteme 只需要一个 gopls ，看 vscode 也是打开项目有一个 gopls ，也翻过 coc 相关的 issues ，但是好像无解，不知道大家是否遇到过，有没有什么解决方法😥

[cocong]

vim 差不多就行了，那么多快捷键谁记得住。

[haoliang]

另外一条路: jedi.vim -> nvim-lspconfig -> nvim-lspconfig + null-ls.nvim -> nvim-lspconfig + null-ls.nvim + copilot.vim

[iamzuoxinyu]

> 这些插件的配置语法几乎都是用 Lua 写的，这让用了 10 年 Vimscript 的我感到极度陌生和恐慌

感同身受，起初我也坚持原教旨 vimscript ，后来想了想，我 10 年都没记住 vimscript 的语法，并且 nvim 也自带了 luajit ，也算 first class ，所以最近终于下定决心全部迁移到 lua 了。

[PTLin]

以前 vim 配着 coc 也凑合用了，但是只是用来看看 c 和配置下脚本，之后听说了 neovim 的存在，当时正好是 0.5 刚刚引入 lua 和内置 lsp 就心血来潮想入坑一波，但是看着太麻烦也懒得学 lua 就放弃了。
前两天有人掘金上写了个 neovim 的小册又心血来潮的买了想学了学，然后我还花了点时间过了下 lua 的语法，之后就开始配 nvim ，真的就是痛苦的开始，这玩意坑实在太太太多了，先不说 breaking change ，就之前用 lsp-installer 配置 rust-tools 就死活没有 hints ，最后搞了半天不用 installer 配置就有了，然后第二天这个 bug 就被修复了。然后就是 rust-tools 的 debug 的 bug ，新版本的 codelldb 上运行不了，我翻了半天 issues 和 pr 才看到是代码的问题，不是我配置错了，然后就是一堆插件的配置之旅调试之旅，我承认，配置好了一个插件确实挺有意思，但是架不住这个过程折磨，我感觉看一个 crate 的 doc 都没看一个插件文档麻烦。
最后我发现我花了几十个小时配置，也就把这个配置成了 vscode 的初始的样子，那我直接 vscode 配上 neovim 插件在加载个脚本就得了，真的懒得配了。

[lanlanye]

用了几年 vim/nvim 了，刚开始折腾各种配置和插件，最后退化到只用 vscode 和它集成的几个简单插件，也就是用来操作括号、注释和快速跳转之类的，终端直接捡现成的 SpaceVim 用了，不过它属实有些复杂，我也没空去研究，就图一个主题+行号之类的默认配置。

哦，总要装的一个插件是 vim-easy-align ，强迫症写 markdown 的表格时离不开它。

[jdhao]

3 年多 nvim 用户，不过没用 coc ，你对 nodejs 有误解，效率不低。我的 nvim 配置，个人更新了很长时间，目前 900 多 star ，欢迎参考使用 https://github.com/jdhao/nvim-config

[reorx]

@jdhao 感谢推荐👍 ，配置写的非常清晰，可以读懂并参考。

其实我知道 Nodejs 在服务端的性能不差，但 Webpack 和 Electron 给我造成的印象已经根深蒂固，使我看到 Nodejs 就会立刻联想到 slow and bloated.

[MCVector]

@Maboroshii 我现在也还在用 ycm. 可能一直没什么问题，懒得换其它的了。

[DrakeXiang]

一直在 vscode 上用 vim 插件，有几次想切换到原生 vim ，但是一个是对文件操作不太熟练和习惯，一个是自动补全当时折腾了一下似乎被 vscode 吊打，还有就是前端生态发展太快，怕 vim 这边没有对应更新的插件，所以还是一直在 vscode 。spacevim 倒是集成了很多东西，但是貌似对键位功能做了很多自定义，我不太喜欢，还是愿意使用原生功能

[hankai17]

刚开始用 ycm 后来环境变来变去 不好安装
于是只用默认 vim

[levelworm]

太折腾，Pycharm 一把梭

[SuperMild]

我现在用 Helix, 类 vim 编辑器，最大的特色是零配置，安装后立即拥有 go to definition 之类的功能，completion 也有但有点弱，勉强够用。

就是零配置太舒服了，有啥用啥，没有的也断了折腾的心思（无插件系统），我从第一天试用就一直用下来，很合我的口味。Rust 制造，运行效率没毛病。

最大的缺点是已经熟悉 vim 的人会很难习惯，因为有些操作与 vim 不同。

[hei1000]

@SuperMild 你是作为日常使用？还没成熟的东西试试还行，作为主工具我有点不放心，毕竟很多东西没做好，而且不知道哪天就不维护了

[herozzm]

在咖啡馆结束了一天的工作=人在美国，刚下飞机
如果不是认真探讨问题而是装，就不会有好的结果

[littlewing]

之前折腾了很久了 vim 插件，最后发现还是 jb 家的 ide 香，现在 vscode 也用得比较多，不过都是装了 vim 插件的，为了用它的键位

[vcfghtyjc]

谢谢分享。我的 vim 自动补全变迁史：折腾了两年 vim 后，用 IDE 然后启动 vim 插件

[saleacy]

@herozzm 不至于

[reorx]

@herozzm 因为 WFH 而日常在咖啡馆工作，挺辛苦的，装不起来啊。。

[drackzy]

我找的网红主播抄的配置，自己又再改改。github 好多别人配置好的可以借鉴。

[reorx]

@vcfghtyjc lol 其实我也越来越依赖 IDE 了，这是我最近 30 天的编辑器使用比例。。

[reorx]

@drackzy 哈哈哈这位确实是最近的网红，却又不同于一般网红那么俗气，我很喜欢他的视频

[cassyfar]

vim 的 lsp 甚至 vscode 的 lsp 都挺玩具的，一到复杂项目就各种问题。工作还是信赖 jetbrain 。

比如 vim 的 clangd 在 mac 下甚至找不到 string.h ，而 clion 已经默认改好了。还有库特别大，比如云计算那些 API ，vim 的 补全没法显示完，最后你还得查文档。

[L4Linux]

@cassyfar 关于 clangd ，你可能需要指定 query driver 。

[cassyfar]

@L4Linux 我找到解决方法了。只是想表示 lsp 的问题不少。

[yazoox]

以前也爱折腾 vim/nvim ，现在... vscode+vim 插件 写代码方便就行。

[ALVC666]

我的最终方案：
jetbrain + ideavim

[yuuko]

> 当时我简单了解后因为它是 nodejs 实现的，就放弃了尝试的念头。开玩笑，jedi 这么一大坨 Python 就慢成这样，nodejs 岂不是更糟糕吗。没想到 coc 一直流行到现在，这似乎再次证明了一个论点，即易用和功能全面才是软件流行的第一因素，无论它的实现有多么不优雅、效率有多么低，只要是能用的、可接受的就行，用户在使用体验上得到满足后，对于小问题的容忍度是相当高的。


无力吐槽，偏见是多么可怕

[GiantHard]

> jedi-vim 虽然开箱即用，但却是一堆粘合在一起的 spaghetti code ，不仅随着项目功能的增加变得越发庞大和迟缓（这是我想要离开 jedi-vim 的主要原因，文件一大各种操作都变得肉眼可见的慢），代码的可读性也非常糟糕，难以维护和参与

这种情况感同身受，遇到了一个非常喜欢的开源软件，但是因为源码太难维护了，不得不去寻找替代品

[vcfvct]

试了几次用 lua 和 native lsp ，还是回到了 COC 其实挺好用的

[xujiahui]

JB 和 vscode 里装了 vim 插件，装 neovim 会改动原生 vim 配置文件吗

[richardwong]

doom emacs 无敌。

[L4Linux]

@cassyfar 那这完全不是 lsp 的问题啊，clion 也用 clangd ，自然也就用了 lsp 。说 clangd 不好用没问题。

[junmoxiao]

"没想到 coc 一直流行到现在，这似乎再次证明了一个论点，即易用和功能全面才是软件流行的第一因素，无论它的实现有多么不优雅、效率有多么低，只要是能用的、可接受的就行，用户在使用体验上得到满足后，"

你这个领悟错了。效率低明显会影响用户体验，coc 效率根本不低，补全速度快

[cassyfar]

@L4Linux 不是啊
正因为 clion 也用，clangd 然后又没问题，所以不是 vim 的问题？

[cassyfar]

@junmoxiao

coc 仁者见仁了。只是好奇既然要用 Vim 又要全套配好，为什么不用 IDE 呢？现在 IDE 都支持 Vim 模式，甚至直接一个 neovim 就跑在那里。

[kran]

这些年我尽量把 vim 配置保持在单文件 200 行以内。还记得入门的第一份配置是在一位叫滇狐的老大哥那拷来的，应该是零几年。

[wuchujie]

@reorx 可以看看你 vim 配置吗。最近换掉 coc 想找个参考参考

[rainysia]

我还在用远古时代的 vundle ，不用 plug 是当时有几个插件有 bug...

[Immortal]

看评论感觉很多人对 vim 的观念还停留在麻烦\困难\快捷键太多记不住等概念,真的深入使用折腾试试会有很大改观,可能会改变你写代码的方式
我也安利给过周围的人,但是很少有共鸣的,感觉会有兴趣的都是喜欢折腾的人,后来我也就放弃安利了
我喜欢看别人(大佬们)的 dotfile,总能捡到很多,如果对 nvim 感兴趣的,可以看下我的 dotfile,比较基础
https://github.com/0x7a7a/dotfiles

[xiaket]

如果你有空折腾的话下一步是换到 init.lua, plug 换到 packer 和折腾 lazy load 提升启动速度了. 刚折腾完的一点心得: https://blog.xiaket.org/2022/pensieve-2204.html

[yuancoder]

现在用的 coc ，懒得折腾什么 lua 了

[Immortal]

@xiaket #51
关于 lazy load 其实是个"假命题",类似于前端的首屏显示速度
一开始我也执着于各种优化启动速度,后来就差不多就行了

具体可以参考这个讨论,后来 jt 也下场讲了下 nvim 中异步的问题:
https://www.reddit.com/r/neovim/comments/opipij/guide_tips_and_tricks_to_reduce_startup_and/

[Immortal]

@Immortal #53
jt => tj

[stdout]

自从不开发 c 系列语言后，vim 的配置已经 n 年没有动过了。大部分时间在 idea 或是 pycharms 或是 node ，他们的 vim 插件几乎不用怎么配置。

[nightwitch]

补全插件一直用 ycm 。
近两年比较大的 vimrc 改动是引入了 leaderf

[chemzqm]

欢迎给 coc.nvim 的问题提交 issues ，每个可复现的 bug 至少可以得到 3 美金 https://v2ex.com/t/846936#reply9
相信楼主这次赚到了。

[7jmS8834H50s975y]

捉到一个 vim 用户，博客欢迎留 友情链接：

https://wsdjeg.spacevim.org/collection/

[xiaket]

@Immortal 的确是要到线就行了, 但是如果是 200ms 以上的话优化一下还是比较明显的.

说回来还是一个体验问题

[reorx]

@wuchujie 我的配置是 https://github.com/reorx/dotfiles/blob/master/nvim/plugs.vim ，但不建议参考，因为只从 cmp 和相关插件的项目主页复制了最基本的配置。

建议参考 #17 的 https://github.com/jdhao/nvim-config ，以及来自我的朋友的 https://github.com/Avimitin/nvim

[reorx]

@chemzqm 别别，我其实对 coc 没有任何意见，自己确实没有用过，本就不该妄加评论。我在博客中已经修改了之前的描述：

> 由于长期受 Webpack 和 Nodejs 技术栈的折磨，当我了解到 coc 是 Nodejs 实现的，就放弃了尝试的念头[^2]。一想到 jedi 的缓慢，我实在没办法对同样大而全的 coc 抱有足够的信心。
> [^2]: 其实 Nodejs 在服务端的性能不差，但 Webpack 和 Electron 给我造成的印象已经根深蒂固，使我看到 Nodejs 就会立刻联想到 slow and bloated.

这两天有许多朋友向我推荐了 coc ，并说明了它的性能是足够好的，我相信它是一个非常棒的插件。

[reorx]

@xiaket 赞，其实我之前有订阅你的博客，前阵子就看到这篇了😄

[reorx]

@wsdjeg SpaceVim 作者你好，文章虽然没提，但我在 2017 年就收藏和使用过 SpaceVim 。回头我给博客加个友链页面把你的主页链上。

[uncat]

vim -> nvim -> ide

\o/

[uncat]

I'm a traitor.

[ruchee]

我现在简单点的编码，用 Vim + snipMate + tags
复杂点的，用 Vim + snipMate + LSP
再复杂点的（主要是前端开发），上 Jetbrians IDE + ideaVim

我是 JB 全家桶付费用户，虽然现在工作基本都在 Terminal 下使用 Vim 完成，导致 IDE 很少开，但付费订阅还是留着，以备不时之需吧

我折腾 Vim 算起来也有 11 年了，那会还没毕业，折腾得很勤快。后面稳定下来了，就很少动了，毕竟工具是拿来用的，够用就行。还是羡慕楼主依然保持着折腾的初心，有折腾才能有进步，挺好的。

[zooo]

vim -> jb 全家桶 -> github copilot

[spark]

用了 10 年 Vim 果断切换到了 VS Code

[junmoxiao]

@cassyfar 我只是反驳作者说的话而已

[h2ero]

感谢分享，同 10 多年的 Vim 用户了，花了几个小时迁移，效率提高太多，切换了很多次 neovim 由于配置之前都是通用的，所以后面都再用 vim ， 折腾了下 Lua ，Lua 还好 AwesomeWM 也是 lua 配置。估计以后都不会回去 Vim 了， 发现 LSP 太爽，VSCode 和 Emacs 很多补全也是用的这个。

[blessingsi]

随着 lua 的引入，这两年 nvim 的社区发展确实快了很多，nvim 版本从 0.5 刷到 0.7 也比之前快了不少，几乎所有的插件都有纯 lua 版本了，甚至还有像 nvim-cmp 作者这样时不时就搞一个 break change 出来的激进玩法。比较担心后面两边会不会越走越远，甚至成为两个社区

[drackzy]

快捷键不用刻意记，有快捷键 popup 提示插件 https://github.com/folke/which-key.nvim

[reorx]

@drackzy 感谢推荐，确实很需要一个这样的工具，有的时候花很大精力配置好了一些快捷键，隔天就忘光了。。

[ilaipi]

@reorx #60 https://github.com/Avimitin/nvim 这个是你朋友的啊，他挺好的我提了好几个问题都帮忙解决了！我用了几个月，终于在今天因为 mac 上安装总是失败换了另外一个 https://github.com/AstroNvim/AstroNvim ，我发现这个可以很方便的自己扩展，几乎不需要修改他的配置。