使用vim/nvim一年之后，说一些真实的感受

使用vim/nvim一年之后，说一些真实的感受

半年之前，我写过一篇《使用vim/nvim半年之后，说一些真实的感受》（链接： 使用vim/nvim半年之后，说一些真实的感受_vim使用体验-CSDN博客），觉得意犹未尽，现在再补充一些。

vim/nvim是个使用其他工具的接口

这点我想单独拿出来讲，是因为这点决定了vim/nvim的使用体验，这里有两点事实：

1. 我们从来都不只是单单使用vim/nvim，而是通过它使用一大堆工具

2. 这些工具能否正常工作会对使用体验带来很大影响

比如我想在vim上启用模糊搜索（这几乎是刚需了），我就选了Leaderf插件，这个插件就要求我vim要支持python3，如果当前Linux自带的vim不支持python3，那么就要重新编译vim，增加了一点点使用麻烦。如果你处于公司内网，不能通过pip安装python软件，那么你的麻烦就增加了很多。

再比如我想在nvim上启用C++自动补全（这也是刚需了），就要安装clangd，但是它在oraclelinux7.9上是运行不起来的，原因是最底层的glibc版本不支持，为了能让clangd跑起来，你的麻烦会增加非常多。

再比如，其实很多插件都是用到ripgrep这个工具的，如果你的linux软件源没提供，那么就得自己编译它，增加了一点点使用麻烦；

再比如，很多插件其实是依赖于nodejs和npm的，如果你的linux不能安装较高版本的nodejs和npm，这插件就用不起来，又增加了一点点使用麻烦。

再比如，插件之间也是有相互依赖的，我的treesitter-textobjects.nvim插件有很长一段时间不工作了，原因也查不出来，后来我无意中PackerSync了一下，把所有插件都更新了一遍，它就能正常工作了。

。。。

这种麻烦列表其实可以很长。

那怎么减少这种麻烦呢？答案就是尽可能使用最新的linux。

Linux版本越新，neovim的体验越好

我现在的开发环境已经迁移到了fedora39+neovim。在搭建这套环境的时候，我只碰到了一两个问题，非常顺利就完成了环境搭建，无他，只因运行环境和工具都是最新的。

对于老Linux上的vim，不要过多追求时髦的功能

我需要在老linux上开发内核模块，这个场景下，就不要过多追求酷炫的功能的，使用最少的插件完成日常需求即可。

比如在oraclelinux7.9上，想编译一下neovim其实都不容易的，依赖的编译器gcc的版本较高，要先安装高版本的gcc。说到这个话题，网上有很多教人如何升级gcc的帖子，都是说要自行下载gcc源码编译安装的，如果你跟着做了，很可能会掉坑。因为gcc和glibc两者的关系密不可分，但glibc是linux最为基础的库，可以把它想象成“更换了glibc就相当于更换了Linux操作系统”，所以如果你因为升级gcc替换了类似于/lib64/libc.so.6这种文件，那么有概率是系统都会启动不了的。比较好的做法就是安装scl版本的高版本gcc，简单而有效。

说回来vim/nvim。

虽然在老linux上使用nvim和时髦功能不容易，但好消息是，使用vim基本没问题的，编译vim的要求也非常低，这意味着，你通常可以打造一个vim9版本+少量插件的环境。不要小看这个组合，使用它们基本上可以满足比较基本的开发需求的。很多人用不好vim，通常是因为vim的基本操作不过关。

我认识一些传统意义上的内核研发高手，他们至今还在使用vi来写代码，而且写出来让人惊叹的优秀的代码，逻辑坚不可摧。对于他们而言，工具的便利性不是必须的，他们对自己写出来的代码和引用的库代码倒背如流，对自动补全的功能的依赖是非常低的。

相对而言，vim+少量插件的使用套装，已经强大很多了。

在高版本linux上使用docker/podman模拟低版本的linux

上面谈到两件事：

1. nvim喜欢跑在fedora3.9上

2. 我的工作要在诸如centos7、oraclelinux7等低版本linux上开发和编译程序

这明显是两个矛盾的事情，怎么调和呢。

答案就是容器技术+编译机。

fedora3.9自带就安装了podman，使用它就可以在fedora上面跑低版本的linux了。只要在Makefile里面写上podman run，就可以在低版本linux里面编译自己的程序。

当然，这样解决不了根本问题。linux内核程序的兼容性是非常严格的，容器里面的centos7只能是让老版本的gcc帮你初步检查你的代码有无问题，最终还是要有真正的centos7的编译一下才能发布，但这一步可以使用专门的编译机器来实现。

具体的选择

上面说了一堆，都是些偏感受的观点，下面是我的一些具体的技术选择，不一定是最好的选择，读者要自行甄别。喜欢玩vim的人，应该都喜欢折腾吧。

大的选择

	阅读内核源码	内核态C编程	用户态C/C++编程
vim/nvim的选择	vim最新版	vim最新版	nvim最新版
LinuxOS	最新的Linux （oraclelinux9/fedora39）	选择主要的目标开发平台	最新的Linux （oraclelinux9/fedora39）

插件和工具的选择

使用需求	阅读内核源码	内核态C编程	用户态C/C++编程
根据函数名搜索等	gtags	leaderf	leaderf
程序之间的跳转	选择gtags+ctags	gtags+ctags+gutentags	LSP(clangd for c++)
插件管理器	无需	vim-plug	lazy.nvim+Mason
在屏幕中自由地移动	无需	vim-easymotion插件	hop.nvim插件
completion自动补全	无需	vim自带	hrsh7th/cmp系列插件
粘贴板支持	xclip或gvim	xclip	xclip
语法高亮	vim自带	vim自带	treesitter
textobjects	无需	kana/vim-textobj系列	treesiter-objects
函数列表	无需	leaderf function	leaderf function
文件树展示	无需	nerdtree	neo-tree

关于nvim套件

vim/nvim有很多套装(或者叫starter pack什么的)，比如astronvim，lazyvim，SpaceVim等等。我只用过astronvim，用得也不多。

既然谈到这里了，我也说一些浅薄之见吧。

套装的好处

套装的好处是显而易见的。

1. 不必自己去寻找插件、甄别同类插件中的优秀者

2. 不会遇到插件之间的冲突

3. 快速安装和配置一堆插件，节省了环境搭建时间

套装的若干问题

1. 真的新手友好吗？如果你对vim本身就不懂得操作，装了个vim套装一样不懂得操作。我的意思是，vim套装并不会降低vim的入门门槛，想入门vim还是要从vim本身的基本操作开始。

2. 套装“遮盖”了插件的功能。套装自动安装了一堆插件，会使得你不知道某个功能是哪个插件完成的，出了问题，连去百度都不知道输入哪个关键字。

3. 套装的原装设置并不能适合每个人。我拿到套装后，还是要根据自身使用场景去调整它的。这就涉及到套装的学习成本了。

4. 套装的学习成本。套装自身有逻辑，比如astronvim，它自身的逻辑还挺多的，那么要改快捷键、自行添加额外的插件、修改它自带插件的行为等等就要参考它的文档，这也是有学习成本的。如果它自身逻辑出了问题，就更难查了。

套装的小结

纵然套装有以上问题，我基本观点还是偏向于使用套装的，但我支持套装有个前提：某个套装能一统天下。

如果某个套装能占据大部分市场，这意味着它的插件选用、快捷键配置会成为行业标准。对我等使用用户来说，我只需习惯一套规则即可，无论我切换操作系统还是升级套装本身，我的使用习惯都不用改变。

当前我是两个都用。在公司是一直使用的散装配置，用了这么久，都习惯了，切换成本太高了；在家里自己瞎折腾就是用astronvim，图个方便。

未来会如何？不得而知。

vim的硬伤

当然是中文输入法的支持，目前没发现很好的解决方案，网上大多的办法是自动切换插件。即安装一个插件，使得你从插入模式转会普通模式时，自动从中文输入法切换回英文输入法。但这样做其实还是麻烦，因为搜索啊等等场景还是中文不友好。

从当前的发展程度来看，如果你的使用场景是中文写作，最好还是不用vim吧。

如果要为程序写文档，我还是选择typora。