V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
reorx
V2EX  ›  程序员

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

  •  5
     
  •   reorx ·
    reorx · 58 天前 · 4529 次点击
    这是一个创建于 58 天前的主题,其中的信息可能已经有所发展或是发生改变。

    原文: 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 的我感到极度陌生和恐慌。

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

    参考链接:

    参考配置:

    结语

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

    74 条回复    2022-05-12 19:05:58 +08:00
    Leviathann
        1
    Leviathann  
       58 天前   ❤️ 1
    jedi 这么一大坨 Python 就慢成这样,nodejs 岂不是更糟糕吗

    这个更糟是怎么来的
    python 从来都是性能洼地啊
    跟 js/ts 没法比
    neilyoone
        2
    neilyoone  
       58 天前
    哈哈哈, 程序员里 vim 用户可不多

    运维用的多 还差不多
    Lionad
        3
    Lionad  
       58 天前
    现在真的是没空折腾编辑器。用 vscode 还是方便很多。vim 只用 basic config 当个 terminal 纯文本编辑器。
    同样的,操作系统也是这样。之前折腾 archlinux ,现在发现还是无脑 macos 或者 windows
    0o0O0o0O0o
        4
    0o0O0o0O0o  
       58 天前 via iPhone   ❤️ 1
    捉虫

    > 我问起了它的 nvim 自动补全配置
    Maboroshii
        5
    Maboroshii  
       58 天前
    最初学习 vim 的时候用 ycm ,后来发现 coc.nvim 很香就一直用了,coc 感觉是个挺复杂的东西,我也没怎么学,就最简单的配置一直在用
    youshangdemajia
        6
    youshangdemajia  
       58 天前
    这种开源软件搭积木的效率和效果比起靠东欧便宜劳动力肝出来的 JetBrains 系 IDE 还是差太多了。
    我用 VIM 的键位足矣,个人认为这是最有价值的。
    reorx
        7
    reorx  
    OP
       58 天前 via iPhone
    @Leviathann 也是,nodejs 做服务端性能不差,我应该是长期使用 webpack 导致的 nodejs 恐惧症
    reorx
        8
    reorx  
    OP
       58 天前 via iPhone
    @youshangdemajia 握手,是的,我有个精简版的单文件配置,专门给 VPS 用
    Buges
        9
    Buges  
       58 天前 via Android
    node 实现应该与复用 vscode 相关 lsp 的生态有关。
    vim 一直都当 np++同类的记事本用,除了基本的语法高亮和简单词汇补全就不多配了,之前试过 https://github.com/AstroNvim/AstroNvim 但主题不能自适应终端亮色 /暗色,再加上体验终归不如 vscode (以 Python 为例,微软的 pylance language server 只许可 vscode 用,开源的 pyright 只管类型,缺乏不少信息)
    ViriF
        10
    ViriF  
       58 天前   ❤️ 2
    nvim 的 virtual text 和 virtual line 目前还是尴尬了一丢丢,导致 inlay hints 目前不能像 idea 和 vs(c)系编辑器一样到位显示;另外就是个人感觉 nvim 插件环境还是挺不稳定的,最近几个月经常能看到 cmp 、lsp/installer 、tele 啥的提示 breaking changes ,虽然有更新就是好事,太频繁了我还是不免有点烦躁
    stevenshuang
        11
    stevenshuang  
       58 天前 via iPhone
    借楼问个问题,之前也在尝试 coc.vim ,只要写 go ,配置 gopls 后,打开项目会启动 4 个 gopls 的进程,但是我之前用 youcompleteme 只需要一个 gopls ,看 vscode 也是打开项目有一个 gopls ,也翻过 coc 相关的 issues ,但是好像无解,不知道大家是否遇到过,有没有什么解决方法😥
    cocong
        12
    cocong  
       58 天前
    vim 差不多就行了,那么多快捷键谁记得住。
    haoliang
        13
    haoliang  
       58 天前
    另外一条路: jedi.vim -> nvim-lspconfig -> nvim-lspconfig + null-ls.nvim -> nvim-lspconfig + null-ls.nvim + copilot.vim
    iamzuoxinyu
        14
    iamzuoxinyu  
       58 天前
    > 这些插件的配置语法几乎都是用 Lua 写的,这让用了 10 年 Vimscript 的我感到极度陌生和恐慌

    感同身受,起初我也坚持原教旨 vimscript ,后来想了想,我 10 年都没记住 vimscript 的语法,并且 nvim 也自带了 luajit ,也算 first class ,所以最近终于下定决心全部迁移到 lua 了。
    PTLin
        15
    PTLin  
       58 天前
    以前 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
        16
    lanlanye  
       58 天前
    用了几年 vim/nvim 了,刚开始折腾各种配置和插件,最后退化到只用 vscode 和它集成的几个简单插件,也就是用来操作括号、注释和快速跳转之类的,终端直接捡现成的 SpaceVim 用了,不过它属实有些复杂,我也没空去研究,就图一个主题+行号之类的默认配置。

    哦,总要装的一个插件是 vim-easy-align ,强迫症写 markdown 的表格时离不开它。
    jdhao
        17
    jdhao  
       58 天前 via Android
    3 年多 nvim 用户,不过没用 coc ,你对 nodejs 有误解,效率不低。我的 nvim 配置,个人更新了很长时间,目前 900 多 star ,欢迎参考使用 https://github.com/jdhao/nvim-config
    reorx
        18
    reorx  
    OP
       58 天前
    @jdhao 感谢推荐👍 ,配置写的非常清晰,可以读懂并参考。

    其实我知道 Nodejs 在服务端的性能不差,但 Webpack 和 Electron 给我造成的印象已经根深蒂固,使我看到 Nodejs 就会立刻联想到 slow and bloated.
    MCVector
        19
    MCVector  
       58 天前
    @Maboroshii 我现在也还在用 ycm. 可能一直没什么问题,懒得换其它的了。
    DrakeXiang
        20
    DrakeXiang  
       58 天前
    一直在 vscode 上用 vim 插件,有几次想切换到原生 vim ,但是一个是对文件操作不太熟练和习惯,一个是自动补全当时折腾了一下似乎被 vscode 吊打,还有就是前端生态发展太快,怕 vim 这边没有对应更新的插件,所以还是一直在 vscode 。spacevim 倒是集成了很多东西,但是貌似对键位功能做了很多自定义,我不太喜欢,还是愿意使用原生功能
    hankai17
        21
    hankai17  
       58 天前
    刚开始用 ycm 后来环境变来变去 不好安装
    于是只用默认 vim
    levelworm
        22
    levelworm  
       58 天前 via Android
    太折腾,Pycharm 一把梭
    SuperMild
        23
    SuperMild  
       58 天前
    我现在用 Helix, 类 vim 编辑器,最大的特色是零配置,安装后立即拥有 go to definition 之类的功能,completion 也有但有点弱,勉强够用。

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

    最大的缺点是已经熟悉 vim 的人会很难习惯,因为有些操作与 vim 不同。
    hei1000
        24
    hei1000  
       58 天前
    @SuperMild 你是作为日常使用?还没成熟的东西试试还行,作为主工具我有点不放心,毕竟很多东西没做好,而且不知道哪天就不维护了
    herozzm
        25
    herozzm  
       58 天前 via Android
    在咖啡馆结束了一天的工作=人在美国,刚下飞机
    如果不是认真探讨问题而是装,就不会有好的结果
    littlewing
        26
    littlewing  
       58 天前
    之前折腾了很久了 vim 插件,最后发现还是 jb 家的 ide 香,现在 vscode 也用得比较多,不过都是装了 vim 插件的,为了用它的键位
    vcfghtyjc
        27
    vcfghtyjc  
       58 天前   ❤️ 2
    谢谢分享。我的 vim 自动补全变迁史:折腾了两年 vim 后,用 IDE 然后启动 vim 插件
    saleacy
        28
    saleacy  
       58 天前 via Android
    @herozzm 不至于
    reorx
        29
    reorx  
    OP
       58 天前
    @herozzm 因为 WFH 而日常在咖啡馆工作,挺辛苦的,装不起来啊。。
    drackzy
        30
    drackzy  
       58 天前

    我找的网红主播抄的配置,自己又再改改。github 好多别人配置好的可以借鉴。
    reorx
        31
    reorx  
    OP
       58 天前
    @vcfghtyjc lol 其实我也越来越依赖 IDE 了,这是我最近 30 天的编辑器使用比例。。
    reorx
        32
    reorx  
    OP
       58 天前
    @drackzy 哈哈哈这位确实是最近的网红,却又不同于一般网红那么俗气,我很喜欢他的视频
    cassyfar
        33
    cassyfar  
       57 天前
    vim 的 lsp 甚至 vscode 的 lsp 都挺玩具的,一到复杂项目就各种问题。工作还是信赖 jetbrain 。

    比如 vim 的 clangd 在 mac 下甚至找不到 string.h ,而 clion 已经默认改好了。还有库特别大,比如云计算那些 API ,vim 的 补全没法显示完,最后你还得查文档。
    L4Linux
        34
    L4Linux  
       57 天前 via Android
    @cassyfar 关于 clangd ,你可能需要指定 query driver 。
    cassyfar
        35
    cassyfar  
       57 天前
    @L4Linux 我找到解决方法了。只是想表示 lsp 的问题不少。
    yazoox
        36
    yazoox  
       57 天前
    以前也爱折腾 vim/nvim ,现在... vscode+vim 插件 写代码方便就行。
    ALVC666
        37
    ALVC666  
       57 天前   ❤️ 1
    我的最终方案:
    jetbrain + ideavim
    yuuko
        38
    yuuko  
       57 天前 via Android   ❤️ 2
    > 当时我简单了解后因为它是 nodejs 实现的,就放弃了尝试的念头。开玩笑,jedi 这么一大坨 Python 就慢成这样,nodejs 岂不是更糟糕吗。没想到 coc 一直流行到现在,这似乎再次证明了一个论点,即易用和功能全面才是软件流行的第一因素,无论它的实现有多么不优雅、效率有多么低,只要是能用的、可接受的就行,用户在使用体验上得到满足后,对于小问题的容忍度是相当高的。


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

    这种情况感同身受,遇到了一个非常喜欢的开源软件,但是因为源码太难维护了,不得不去寻找替代品
    vcfvct
        40
    vcfvct  
       57 天前 via Android
    试了几次用 lua 和 native lsp ,还是回到了 COC 其实挺好用的
    xujiahui
        41
    xujiahui  
       57 天前
    JB 和 vscode 里装了 vim 插件,装 neovim 会改动原生 vim 配置文件吗
    richardwong
        42
    richardwong  
       57 天前
    doom emacs 无敌。
    L4Linux
        43
    L4Linux  
       57 天前 via Android
    @cassyfar 那这完全不是 lsp 的问题啊,clion 也用 clangd ,自然也就用了 lsp 。说 clangd 不好用没问题。
    junmoxiao
        44
    junmoxiao  
       57 天前
    "没想到 coc 一直流行到现在,这似乎再次证明了一个论点,即易用和功能全面才是软件流行的第一因素,无论它的实现有多么不优雅、效率有多么低,只要是能用的、可接受的就行,用户在使用体验上得到满足后,"

    你这个领悟错了。效率低明显会影响用户体验,coc 效率根本不低,补全速度快
    cassyfar
        45
    cassyfar  
       57 天前
    @L4Linux 不是啊
    正因为 clion 也用,clangd 然后又没问题,所以不是 vim 的问题?
    cassyfar
        46
    cassyfar  
       57 天前
    @junmoxiao

    coc 仁者见仁了。只是好奇既然要用 Vim 又要全套配好,为什么不用 IDE 呢?现在 IDE 都支持 Vim 模式,甚至直接一个 neovim 就跑在那里。
    kran
        47
    kran  
       57 天前 via Android
    这些年我尽量把 vim 配置保持在单文件 200 行以内。还记得入门的第一份配置是在一位叫滇狐的老大哥那拷来的,应该是零几年。
    wuchujie
        48
    wuchujie  
       57 天前
    @reorx 可以看看你 vim 配置吗。最近换掉 coc 想找个参考参考
    rainysia
        49
    rainysia  
       57 天前
    我还在用远古时代的 vundle ,不用 plug 是当时有几个插件有 bug...
    Immortal
        50
    Immortal  
       57 天前
    看评论感觉很多人对 vim 的观念还停留在麻烦\困难\快捷键太多记不住等概念,真的深入使用折腾试试会有很大改观,可能会改变你写代码的方式
    我也安利给过周围的人,但是很少有共鸣的,感觉会有兴趣的都是喜欢折腾的人,后来我也就放弃安利了
    我喜欢看别人(大佬们)的 dotfile,总能捡到很多,如果对 nvim 感兴趣的,可以看下我的 dotfile,比较基础
    https://github.com/0x7a7a/dotfiles
    xiaket
        51
    xiaket  
       57 天前
    如果你有空折腾的话下一步是换到 init.lua, plug 换到 packer 和折腾 lazy load 提升启动速度了. 刚折腾完的一点心得: https://blog.xiaket.org/2022/pensieve-2204.html
    yuancoder
        52
    yuancoder  
       57 天前
    现在用的 coc ,懒得折腾什么 lua 了
    Immortal
        53
    Immortal  
       57 天前
    @xiaket #51
    关于 lazy load 其实是个"假命题",类似于前端的首屏显示速度
    一开始我也执着于各种优化启动速度,后来就差不多就行了

    具体可以参考这个讨论,后来 jt 也下场讲了下 nvim 中异步的问题:
    https://www.reddit.com/r/neovim/comments/opipij/guide_tips_and_tricks_to_reduce_startup_and/
    Immortal
        54
    Immortal  
       57 天前
    @Immortal #53
    jt => tj
    stdout
        55
    stdout  
       57 天前
    自从不开发 c 系列语言后,vim 的配置已经 n 年没有动过了。大部分时间在 idea 或是 pycharms 或是 node ,他们的 vim 插件几乎不用怎么配置。
    nightwitch
        56
    nightwitch  
       57 天前
    补全插件一直用 ycm 。
    近两年比较大的 vimrc 改动是引入了 leaderf
    chemzqm
        57
    chemzqm  
       57 天前
    欢迎给 coc.nvim 的问题提交 issues ,每个可复现的 bug 至少可以得到 3 美金 https://v2ex.com/t/846936#reply9
    相信楼主这次赚到了。
    wsdjeg
        58
    wsdjeg  
       57 天前
    捉到一个 vim 用户,博客欢迎留 友情链接:

    https://wsdjeg.spacevim.org/collection/
    xiaket
        59
    xiaket  
       57 天前
    @Immortal 的确是要到线就行了, 但是如果是 200ms 以上的话优化一下还是比较明显的.

    说回来还是一个体验问题
    reorx
        60
    reorx  
    OP
       57 天前
    @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
        61
    reorx  
    OP
       57 天前
    @chemzqm 别别,我其实对 coc 没有任何意见,自己确实没有用过,本就不该妄加评论。我在博客中已经修改了之前的描述:

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

    这两天有许多朋友向我推荐了 coc ,并说明了它的性能是足够好的,我相信它是一个非常棒的插件。
    reorx
        62
    reorx  
    OP
       57 天前   ❤️ 1
    @xiaket 赞,其实我之前有订阅你的博客,前阵子就看到这篇了😄
    reorx
        63
    reorx  
    OP
       57 天前
    @wsdjeg SpaceVim 作者你好,文章虽然没提,但我在 2017 年就收藏和使用过 SpaceVim 。回头我给博客加个友链页面把你的主页链上。
    uncat
        64
    uncat  
       57 天前
    vim -> nvim -> ide

    \o/
    uncat
        65
    uncat  
       57 天前
    I'm a traitor.
    ruchee
        66
    ruchee  
       57 天前
    我现在简单点的编码,用 Vim + snipMate + tags
    复杂点的,用 Vim + snipMate + LSP
    再复杂点的(主要是前端开发),上 Jetbrians IDE + ideaVim

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

    我折腾 Vim 算起来也有 11 年了,那会还没毕业,折腾得很勤快。后面稳定下来了,就很少动了,毕竟工具是拿来用的,够用就行。还是羡慕楼主依然保持着折腾的初心,有折腾才能有进步,挺好的。
    zooo
        67
    zooo  
       57 天前
    vim -> jb 全家桶 -> github copilot
    spark
        68
    spark  
       57 天前
    用了 10 年 Vim 果断切换到了 VS Code
    junmoxiao
        69
    junmoxiao  
       56 天前
    @cassyfar 我只是反驳作者说的话而已
    h2ero
        70
    h2ero  
       56 天前
    感谢分享,同 10 多年的 Vim 用户了,花了几个小时迁移,效率提高太多,切换了很多次 neovim 由于配置之前都是通用的,所以后面都再用 vim , 折腾了下 Lua ,Lua 还好 AwesomeWM 也是 lua 配置。估计以后都不会回去 Vim 了, 发现 LSP 太爽,VSCode 和 Emacs 很多补全也是用的这个。
    blessingsi
        71
    blessingsi  
       56 天前
    随着 lua 的引入,这两年 nvim 的社区发展确实快了很多,nvim 版本从 0.5 刷到 0.7 也比之前快了不少,几乎所有的插件都有纯 lua 版本了,甚至还有像 nvim-cmp 作者这样时不时就搞一个 break change 出来的激进玩法。比较担心后面两边会不会越走越远,甚至成为两个社区
    drackzy
        72
    drackzy  
       54 天前   ❤️ 1
    快捷键不用刻意记,有快捷键 popup 提示插件 https://github.com/folke/which-key.nvim
    reorx
        73
    reorx  
    OP
       54 天前
    @drackzy 感谢推荐,确实很需要一个这样的工具,有的时候花很大精力配置好了一些快捷键,隔天就忘光了。。
    ilaipi
        74
    ilaipi  
       54 天前
    @reorx #60 https://github.com/Avimitin/nvim 这个是你朋友的啊,他挺好的我提了好几个问题都帮忙解决了!我用了几个月,终于在今天因为 mac 上安装总是失败换了另外一个 https://github.com/AstroNvim/AstroNvim ,我发现这个可以很方便的自己扩展,几乎不需要修改他的配置。
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1284 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 18:42 · PVG 02:42 · LAX 11:42 · JFK 14:42
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.