1. RHEL 上的 vim 为什么总像缺了半条命新装完一台 RHEL 机器很多人第一件事就是vi /etc/xxx.conf然后发现语法高亮没有缩进是硬 Tab插入模式下按退格键光标不动、屏幕上只冒出一个字符方向键在插入模式里吐出A B C D敲一句:syntax on直接回你一个 E319。第一反应是这台机器有问题第二反应是我是不是进错编辑器了。都没错你进的确实是 vim只不过是最小的那个 vim。RHEL 的软件包策略把 vim 拆成了好几块最小化安装默认只落下vim-minimal它提供的/bin/vi是编译时把功能砍到small级别的版本。这个版本的定位很清楚系统装好那一刻万一网络不通、万一没有别的编辑器我得保证有个能改配置文件的东西。它不负责让你用得爽。所以三分钟启动完整版 vim这件事本质上不是在装一个软件而是在把一台机器上被刻意阉割掉的编辑器能力重新补回来。这篇内容就是我自己在几十台 RHEL 机器上反复走的一条路不走仓库包、不引入外部源直接从 Vim 9 的源码编译一个--with-featureshuge的完整版全程三分钟左右。适合两类人看一类是刚接手 RHEL 服务器、被vi折磨到怀疑人生的新手另一类是嫌仓库里的vim-enhanced不够用、想要python3 lua clipboard全都点亮的老手。1.1 先搞清楚系统里那个vi是什么来路在动手之前值得花三十秒看清现状不然你会对后面发生的事一头雾水。RHEL 把 vim 相关内容切成了几个包vim-minimal提供/bin/vi是那个功能被裁到最小的版本vim-enhanced提供/usr/bin/vim特性等级通常是huge但发行版出于依赖管理的考虑往往把 Perl、Ruby、Lua 这些解释器支持全部关掉Python 支持也时有时无此外还有vim-common、vim-filesystem之类的公共文件包。这套切分带来的直接后果是你dnf install vim-enhanced之后:echo has(python3)可能依然是 0:echo has(lua)更是想都别想。不是包坏了是编译参数里根本没开。发行版不可能为了一个编辑器的脚本能力把一堆语言运行时塞进基础依赖里这是发行版的合理选择但对想把 vim 当 IDE 用的人来说就很难受。顺带说一句解释器支持为什么重要。python3不是让你在 vim 里写 Python 玩而是让大量插件能跑起来补全、语法检查、模糊查找、Markdown 预览这些生态里的主力插件基本都依赖 Python3 接口。lua在老牌配置框架里用得更多。少了这些你的插件管理器装完一堆插件启动时报一串requires python3 support那种挫败感比没有插件还难受。1.2 一张表看清 small 和 huge 到底差在哪Vim 编译时有个特性等级的概念从低到高是tiny、small、normal、big、huge。它不是简单的加几个功能而是一整套开关的组合选高一档就自动带上几十个xxx。下面的对照表是我按实际使用感受整理的只挑日常最有感知的几项能力small系统默认vihuge本文目标实际影响语法高亮syntax无有配置文件、代码全是单色找错全靠眼睛多级撤销persistent_undo无有只能u一次重启后撤销历史清零代码折叠folding无有上千行的配置没法按段收起插件加载eval完整支持受限完整大量现代插件跑不起来解释器接口全无python3、lua、perl、ruby补全、检查、预览类插件不可用系统剪贴板clipboard无有需 X11 库跨窗口复制粘贴只能靠手打鼠标与终端特性基本无mouse、terminal不能拖选、不能开内置终端分屏真彩色termguicolors无有主题配色只能退化成 256 色最后一行值得单独提一句。很多人装完主题发现颜色发灰、和截图完全不是一回事问题就出在termguicolors上。这个特性在huge里默认带上small里没有而它决定了 vim 能不能吃下终端送过来的 24 位色值。颜色不对的时候先别怀疑主题坏了:echo has(termguicolors)看一眼更省时间。1.3 仓库包、外部源、源码编译为什么我选第三条三条路摆在面前各有各的账。第一条是仓库包dnf install vim-enhanced五秒钟搞定但特性被裁剪、版本被锁定RHEL 9 上你可能拿到的是一个补丁级别落后半年的 9.0想要新特性只能等下一个次版本。第二条是引入外部软件源能拿到打包好的全功能版本但它会往系统里塞进额外的仓库配置和 GPG 信任离线环境、安全审计严格的场景基本走不通。第三条是源码编译代价是多了三分钟的操作和一点点维护成本换来的是特性开关完全由你决定编译出来的东西不归包管理器管版本随时换离线环境照样能做。而且 Vim 的编译流程相当干净——没有复杂的构建系统没有一堆外部代码生成步骤configuremake两步走完这点在如今这个编译一个编辑器要先装半个工具链的年代已经很难得了。时间账我也摆一下让你心里有数补齐依赖在网速正常的情况下 20 秒左右configure30 秒上下make -j在 4 核机器上 60 到 90 秒make install3 秒。所谓三分钟指的是从敲下第一条dnf到vim --version打出9.x的全过程不是夸张说法但也别指望单核老机器能压进这个数。2. 编译前的家底清点与依赖补齐编译这件事最容易翻车的环节从来不是make而是我以为我装齐了。缺少ncurses-devel的时候configure会一路跑到最后才给你一句no terminal library found前面的输出全是绿的特别容易让人以为成功了。2.1 三条命令摸清系统底子在装任何东西之前先确认几件事这些信息直接决定后面configure该怎么写cat /etc/redhat-release # 确认是 RHEL 8 还是 9决定默认解释器版本 nproc free -h # 决定 make -j 开多大 vim --version | head -3 # 看清现有 vim 的版本和编译者信息 python3 --version # 记下默认 python3 的小版本号为什么要专门看 Python 版本因为 Vim 的configure会去找系统默认的python3及其头文件如果你装的是python3-devel但--with-python3-command指到了另一个版本编译出来的结果就是-python3而且不会有明显报错只在最后汇总里埋一个减号。RHEL 8 默认是 Python 3.6部分场景是 3.9 模块流RHEL 9 默认 3.9两者头文件路径不同配置时对不齐是很常见的坑。nproc也不能忽略。并行编译不是核越多越好每个编译单元大约要吃 200 到 300MB 内存一台 2G 内存的 8 核小机器上make -j8大概率在链接阶段被内核的 OOM killer 干掉症状是cc1: out of memory或者干脆make被信号杀死。稳一点的经验值内存 GB 数乘 1.5和核数取小值。4G 内存 8 核的机器make -j4比make -j8快因为在并行和换页之间后者全花在 swap 上了。2.2 依赖清单每个-devel包到底换来了什么下面这张表是我实际编译时对照用的左边是包中间是它在编译期起的作用右边是漏装之后你会看到的现象。装依赖的时候不要照着某篇旧教程抄命令RHEL 8 和 9 的包名有细微差别用表里的思路自己核对更靠谱。包名换来的能力漏装的后果gcc、make编译器与构建工具起手就command not foundncurses-devel终端库的tgetent系列符号configure末尾报no terminal library found直接中断python3-develpython3:echo has(python3)返回 0插件全废perl-devel、perl-ExtUtils-Embedperlperl变-perl老插件报错ruby-develruby同上lua-devellua配置框架的部分 Lua 插件加载失败libXt-devel、libX11-devel、libSM-devel、libICE-develclipboard、xterm_clipboard只能靠 OSC 52 方案或干脆手打git或tar拿源码后面所有步骤无从谈起一条命令把它们全装上实测下来 20 秒内能完成sudo dnf install -y gcc make ncurses-devel \ python3-devel perl-devel perl-ExtUtils-Embed ruby-devel lua-devel \ libXt-devel libX11-devel libSM-devel libICE-devel有一个包值得单独说明perl-ExtUtils-Embed。很多教程只写perl-devel结果编译完发现 Perl 接口还是没开。原因是 Vim 在configure阶段会调用ExtUtils::Embed这个 Perl 模块来探测嵌入参数缺了它探测失败configure就静默地把 Perl 支持关掉不报错、不警告只在最后的特性汇总里留一个-perl。这种静默降级是整件事里最阴的一类问题。至于lua-develRHEL 的仓库里不一定每个小版本都有装不上就直接跳过Lua 支持对日常编辑的影响远小于 Python3属于锦上添花。反过来如果你明确不要系统剪贴板比如纯远程终端、后面打算走 OSC 52那把libXt、libX11那一串全部省掉configure时加--without-x编译时间还能再省十几秒。2.3 源码拿哪个版本、怎么拿拿源码有两种方式下载官方发布的vim-9.x.xxxx.tar.gz源码包或者用版本库克隆一份。源码包的好处是稳定、自包含、自带已经生成好的configure脚本解压就能用版本库的好处是随时能切到某个具体补丁版本。日常使用我推荐源码包因为 Vim 的补丁发布极其频繁一年上千个补丁版本库里每天都有变化除非你在追某个特定修复否则没必要。解压后先不要急着configure花两秒确认两件事src/configure文件存在且可执行src/version.c里的主版本号确实是 9。有些第三方打包的源码包会做二次加工版本号对不上后面排查起来很痛苦。tar xf vim-9.1.xxxx.tar.gz cd vim-9.1.xxxx ls -l src/configure grep -m1 VIM_VERSION_MAJOR src/version.c3. configure 参数从--with-featureshuge说起--with-featureshuge只是起点它决定了功能骨架但真正决定你能不能用上 Python 补全、能不能跨窗口复制粘贴的是后面那几个开关。参数写错不会报错只会让你的vim --version里多几个减号然后你在某个插件报错的时候才发现。3.1 prefix 定在/usr/local还是/opt这是整个安装过程中最值得想清楚的一个决定因为它决定了后面所有的路径问题。装到/usr/local是最省事的/usr/local/bin在 RHEL 的默认PATH里排在/usr/bin前面装完直接vim就是新的不用改任何环境变量。缺点是它和系统包的边界不够清晰将来make uninstall或者手工清理时你得记住哪些文件是自己的。装到/opt/vim9则是另一种思路完全隔离一个目录里装下所有东西升级时新版本解压到/opt/vim9-new验证没问题后把软链切过去回滚只需把软链切回来干净到有点强迫症。代价是要自己处理PATH和runtime路径多两行配置。我在需要长期维护、会反复升级的机器上走第二种一次性配好的临时机器走第一种。不管选哪个有一条铁律绝对不要装到/usr。那会直接覆盖包管理器管辖的文件rpm -V vim-enhanced会报一堆校验失败系统升级时可能出现半新半旧的奇妙状态出了问题很难复原。3.2 逐条拆参数知道每个开关在干什么下面按重要性排一下我常用的参数以及为什么这么写参数作用说明--with-featureshuge打开最大特性集这是完整版的核心其余参数都是在此基础上的增补--enable-multibyte多字节字符支持Vim 8 之后默认开启写上去是自我提醒避免有人手工加--disable-multibyte--enable-python3interpyes动态加载 Python3配合--with-python3-command指定解释器两者必须指向同一套--with-python3-commandpython3明确解释器路径不写的话靠自动探测多 Python 环境下容易探错--enable-perlinterpyesPerl 接口需要perl-ExtUtils-Embed否则静默关闭--enable-rubyinterpyesRuby 接口老插件用得多--enable-luainterpyesLua 接口仓库有lua-devel就开没有就删掉这行--enable-cscopecscope 支持读大代码库时有用成本极低--enable-terminal内置终端:terminal免切窗口跑命令huge里已包含显式写上更保险--enable-fontset字体集支持主要给 GUI 版用命令行下无副作用--enable-guino不编译 GUI服务器上没必要省编译时间--with-compiledby自己认识的名字标记编译者这行很实用:version里一眼能看出这是自己编的不是系统的--prefix/usr/local安装前缀决定所有文件落点--with-compiledby这个参数看起来无关紧要实际用起来很爽。机器多了之后经常忘了某台机器上的 vim 是哪来的:version第一屏扫一眼编译者字段立刻就能确认。我一般写成机器角色加日期比如build-2024-web比写自己名字有用得多。3.3 两套完整命令按需选一套全功能版带系统剪贴板支持适合有桌面环境或者经常在本地终端和 vim 之间倒腾文本的场景./configure \ --with-featureshuge \ --enable-multibyte \ --enable-python3interpyes \ --with-python3-commandpython3 \ --enable-perlinterpyes \ --enable-rubyinterpyes \ --enable-luainterpyes \ --enable-cscope \ --enable-terminal \ --enable-fontset \ --enable-guino \ --with-compiledbyrhel-local-build \ --prefix/usr/local纯服务器版砍掉 X11 相关编译更快靠 OSC 52 解决剪贴板问题./configure \ --with-featureshuge \ --enable-multibyte \ --enable-python3interpyes \ --with-python3-commandpython3 \ --enable-cscope \ --enable-terminal \ --enable-guino \ --without-x \ --with-compiledbyrhel-server-build \ --prefix/opt/vim9configure跑完一定要看最后那段汇总不是看有没有error而是看特性清单里该是加号的地方是不是加号。我的习惯是把输出重定向到文件再grep一遍关键项./configure ... 21 | tee /tmp/vim-conf.log grep -E checking for (python3|lua|perl|ruby|tgetent)|features /tmp/vim-conf.log这一步多花十秒能省掉后面二十分钟的重编。我吃过这个亏有一次configure输出刷了两屏我直接make了装完发现 Python 没开回头一看日志里明明白白写着checking for python3... no原因是当时python3-devel还没装完我就开始编译了。4. 三分钟走完编译安装参数定好之后剩下的事情就是等。这一段没有技术含量但有几个细节能让结果更可控。4.1make -j的并行度与失败重来make -j$(nproc)前面说过并行度不能盲给。如果编译到一半被杀死不要直接重来先把源码树清一下再继续否则残留的目标文件可能让你在链接阶段收到一堆莫名其妙的符号错误make distclean ./configure ... make -j4make distclean和make clean的区别值得记一下clean只删目标文件保留configure的产物distclean连Makefile、config.status一起删掉回到刚解压的状态。参数改了之后重编一定要用distclean否则旧的config.status会把你的新参数覆盖回去你会得到一个明明改了参数却完全没生效的灵异现象。编译过程中如果看到warning绝大多数不用管Vim 源码在各个编译器版本下都会吐一些警告。真正要盯的是error以及链接阶段出现的undefined reference to后者基本都指向同一个原因某个-devel包没装。4.2make install之后为什么敲vim还是老的这是新手最容易卡住的地方也是三分钟变成半小时的元凶。安装完成后如果vim --version显示的版本没变按这个顺序排查which -a vim # 看 PATH 里到底有几个 vim顺序如何 /usr/local/bin/vim --version | head -1 # 直接写全路径验证是否装成功 hash -r # 清掉 bash 的命令路径缓存bash 会缓存已经找到的命令路径make install之后不清缓存你在同一个 shell 里敲vim走的还是旧路径。hash -r一行解决很多人不知道这个非得开个新终端才发现原来装好了。如果是装到/opt/vim9还要自己加 PATH。写进/etc/profile.d/vim9.sh比写个人.bashrc合适前者对所有用户生效后者只对自己生效echo export PATH/opt/vim9/bin:$PATH | sudo tee /etc/profile.d/vim9.sh同时记得处理 RHEL 自带的一个小脚本/etc/profile.d/vim.sh。它会给非 root 用户设置alias vivim如果你的vim还指向/usr/bin/vim那这个 alias 就把你带回了老版本。最干净的处理方式是后面要讲的 alternatives把vi这个命令名本身接管掉alias 就无所谓了。4.3 用 alternatives 统一接管vi和vimalternatives是 RHEL 系的命令版本管理机制用它比自己维护软链靠谱得多因为它会记录优先级、支持一键切换、升级时不会打架sudo alternatives --install /usr/bin/vi vi /usr/local/bin/vim 100 sudo alternatives --install /usr/bin/vim vim /usr/local/bin/vim 100 sudo alternatives --display vi优先级数字越大越优先给到 100 基本能压过系统默认的一批。装完之后vi、vim、view全部指向新的二进制alternatives --config vi还能在需要的时候切回系统版本做对比。这一步做完前面那些alias、PATH、hash的问题基本一次性解决。5. 装完必须验证的四件事编译安装最容易出现的心理错觉是装完了就等于装对了。下面这四项检查我每次都会过一遍加起来不到一分钟能挡住后面 90% 的莫名其妙。5.1 特性清单核对别用眼睛扫用脚本vim --version那两行加号减号密密麻麻肉眼扫根本不可靠。写个小循环对一遍输出清清爽爽wantmulti_byte syntax folding persistent_undo python3 lua cscope terminal termguicolors mouse have$(vim --version | grep -Eo [-][a-z0-9_] | tr \n ) for f in $want; do case $have in * $f *) echo OK $f ;; *) echo MISS $f ;; esac done有MISS就回到/tmp/vim-conf.log里找对应的checking for xxx... no原因和处置基本都是确定的。这个脚本我放在 dotfiles 里换机器第一件事就是跑它。5.2$VIMRUNTIME必须指向新目录这条比特性清单还重要但几乎没人检查。vim --version显示的是二进制的能力而$VIMRUNTIME决定它加载哪一套运行时文件语法文件、缩进文件、主题、文档。如果二进制是新的、runtime 还是系统旧的/usr/share/vim/vimXX你会遇到各种诡异问题语法高亮失效、主题加载报错、help打不开、某些命令提示不认识。vim -es echo $VIMRUNTIME q正常情况下应该输出/usr/local/share/vim/vim91或者/opt/vim9/share/vim/vim91这样的路径版本号要和你编译的主次版本对上。如果是系统旧路径检查是不是PATH里混进了旧二进制或者VIMRUNTIME被.bashrc里某个残留的export硬指定了。这个环境变量一旦被硬编码优先级高于自动推导会让你的新二进制用旧运行时症状极其难查。5.3 颜色不对先查三个地方主题装好之后颜色发灰、背景一片死黑、注释和字符串一个色按这个顺序查别一上来就换主题检查项命令期望结果终端色数tput colors256 或以上真彩色支持echo $COLORTERMtruecolor或24bitvim 真彩色特性:echo has(termguicolors)1是否启用:set termguicolors?termguicolors前三项都没问题、颜色还是不对八成是第四项没开。termguicolors默认不开需要在配置里显式set termguicolors。另一个常见情况是终端模拟器本身不支持 24 位色这时候$COLORTERM是空的tput colors也只会返回 8 或 16——那不是 vim 的问题换终端才有解。5.4 剪贴板X11 库和 OSC 52 两条路clipboard只表示这个二进制有能力访问系统剪贴板真正能不能用还要看运行环境。如果是本地图形终端里开的 vimy直接就能复制如果是通过远程连接进来的纯文本会话X11 那一套根本没有落脚点y会静默失败寄存器里其实有内容但系统剪贴板拿不到。纯远程场景有两个解法。一是走 X11 转发前提是本地有 X server、连接时开了转发、并且装了xauth之类的配套组件——能通就通通不了折腾起来很费劲。二是走 OSC 52 转义序列终端模拟器支持的话vim 把文本用一段控制序列写到终端由终端自己去接管系统剪贴板完全绕开 X11。近年主流的终端模拟器对这个序列的支持已经很普及了缺点是有些环境出于安全考虑会禁用这条通道此时复制会静默失败而且没有任何报错。我自己的判断标准很简单本地干活就编译全功能版clipboard一把梭纯远程运维就编无 X 版本配一个 OSC 52 的小插件专门处理复制剩下的交给:w !pbcopy之类的命令兜底。6. 踩坑速查与经验沉淀编译 Vim 这件事成功路径只有一条失败路径有十几条而且大部分失败都是静默的。下面这些是我这些年攒下来的对照表遇到问题先查表比重新读一遍configure --help快得多。6.1 症状、原因、处置速查表症状最可能的原因处置configure末尾报no terminal library found缺ncurses-devel装上后distclean重来:echo has(python3)返回 0python3-devel缺失或解释器版本对不上检查--with-python3-command与python3-config --prefix是否同一套perl变成-perl缺perl-ExtUtils-Embed补装后重新configuremake中途被信号杀死并行度过高触发 OOM降到-j2或-j4装完vim --version版本没变shell 命令缓存或PATH顺序hash -rwhich -a vim确认语法高亮全失效$VIMRUNTIME指向旧目录检查环境变量确认指向新share/vim/vimXX主题颜色发灰未开启termguicolors或终端不支持真彩色按 5.3 的顺序逐项排查y无反应无 X11 环境改走 OSC 52或用重定向命令兜底启动报E117: Unknown function运行时版本低于二进制的补丁级别用源码树里的runtime覆盖或对齐版本make install权限不足未提权且prefix在系统目录sudo make install或改prefix到用户目录表格里最后第二行那个E117很少见但很坑如果你从版本库拉的是最新代码编译出来的二进制补丁级别很高而安装时只装了二进制没更新运行时文件就会出现二进制认识某个函数、运行时文件里没有这个函数的错配。正常make install会一起装出问题基本都发生在手工拷二进制的时候。6.2 几条不太写进文档的经验第一条先做一次DESTDIR演练。在正式install之前用make install DESTDIR/tmp/vimstage把文件装到一个临时目录里find /tmp/vimstage -type f | head -50看一眼它到底往哪些路径写了东西。这个动作能让你在十几秒内搞清楚这套安装的边界将来要手工清理或者做打包心里有底。我第一次在别人的生产机器上装的时候没做这步后来想卸载发现make uninstall需要原始源码树源码树早被清理掉了只能靠find按时间戳一个个捞非常狼狈。第二条保留一份--version快照。装完立刻vim --version ~/.vim-build-info.txt里面包含完整的编译参数和特性清单。半年后你想知道这台机器上的 vim 是怎么编的这份文件比任何记忆都可靠。同名文件在换机器时直接对比能一眼看出两台机器的差异排查为什么这台机器插件能跑那台不能的效率能提高好几倍。第三条升级不要原地覆盖。Vim 的主次版本之间运行时文件布局偶尔会变原地make install覆盖可能出现新旧文件混杂。我的做法是装到带版本号的目录/opt/vim9用软链指向当前版本升级时新版本装到/opt/vim9-new验证通过后ln -sfn切过去。回滚就是把软链切回来两秒钟的事不需要重新编译。这个习惯是从一次升级后help全部失效的事故里学来的那次排查花了整整一个下午。第四条编译时间不是越长越好。有人喜欢在configure里把所有能想到的开关全开包括各种图形界面后端。GUI 后端会引入一大串图形库依赖编译时间翻倍而你在服务器上根本用不到。开关的边际收益递减得很快python3带来的收益占八成剩下的lua、ruby、perl属于有更好、没有也能活。我现在的标准配置就是hugepython3cscopeterminal其他看机器用途决定。第五条别把vi的兼容模式当 bug。偶尔有人反馈我的 vim 行为特别怪退格不能删、方向键乱跳、撤销只有一级一问都是用vi命令启动的。vi在某些配置下会进入兼容模式行为和传统 vi 一致。:set compatible?一看便知:set nocompatible就恢复了。这个问题和编译无关但和我明明装了完整版为什么还是难用的困惑高度相关值得单独记一笔。最后分享一个我自己用着挺顺手的小习惯把编译脚本存成~/build-vim.sh参数、依赖安装、验证核对全部串在一起换机器直接跑。到现在这个脚本已经迭代了十几版每次踩坑就往里加一行检查现在跑到最后一步会自己打印一份特性对照绿色的OK一路刷下来那种感觉比装完就完事踏实多了。
