作者:LiTuX
链接:https://www.zhihu.com/question/24294358/answer/27362814
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
链接:https://www.zhihu.com/question/24294358/answer/27362814
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
早些年,vim 插件只能自己扔到 ~/.vim 或者 vimfiles 里面,由于插件的结构很 unix,于是同一个插件,plugin, ftplugin, doc, syntax 等等文件夹下面灰常混乱的存在着各种东西,而且要用户自己管理安装、升级、卸载、配置。好特么烦!
然后,*nix 平台上有人受不了了,弄过几个独立的第三方插件管理器, 比如这里面有个东东叫 vim addon manager(请记住这个名字 XD) (当然,请原谅我,还有好几个类似的东东我都忘了叫啥了,有谁知道欢迎补充) 。 vam 是 ruby 写的, 看名字就知道丫是干嘛用的 , 不过…… 我没用过它所以没法评价 (曾经“用过”的一个第三方管理器叫 vimana,什么表现嘛我就不记得了)。
但这种第三方的一般都是某种脚本语言写的,在 *nix 上还好,让我们 windows 用户肿么办……然后,有个灰常霸气的东东出现了,——vimball。这货可以看做是 vim 界的 docstrip(其实更简洁),简直是个神器。从此装插件易如反掌,麻麻再也不用担心我不会装插件啦!三个咒:
直接搞定了有木有!卸载也就一行命令的事(嗯?好像没用过哎)。唯一需要对付的是,——你要的插件需要提供那个 vba 才行(而且这个插件应该是纯 vim script)。
于是这就有了限制。那其他的呢尤其是提供 zip/tarball 的咋办。基于 vimball 修改 runtimepath 的理念,一个更加没有限制的插件“管理器”诞生了,这货叫 pathogen(by tpope 大神)。只需把你的 tarball 整个解到 pathogen 的管理目录(bundle)下,vimrc 稍作处理,这个插件就可以用啦!曾经那个混乱的目录结构 sayonara~~ 插件管理变成文件管理,很方便有木有!
可是,懒惰的人们嫌这个还不够。刚好,github 流行起来,很多 vim 插件的作者都将插件放到 github 上托管。于是有人通过 git module 来管理自己的 vim 插件,以达到“一份 vimrc 走遍天下”的目的,不需要自备 vimfiles 目录。在这个背景下,划时代的插件管理器终于诞生了,这货叫 vundle(by gmarik。顺便提一句,vundle 刚不久前经历了一次大版本升级,主要命令发生了变化,请用户注意)。
vundle 诞生之后,很长时间内这成为了众多 vimmer 的标配(至今仍是),这货一定程度上真正达到了一个 vimrc 搞定一切的“终极”目标,——对大部分插件尤其全部是 vim script 至多依赖 +python/+lua 等的插件而言,vundle 足够方便足够简洁,并且有着足够实用的管理方式:安装、升级、停用、卸载都仅需一条命令,必须是 life changing 的评分。唯一需要的是,你用的插件在 github 上有对应的 repo,或者 http://vim.org 上注册存在,并且你要有个能用的 git。
然后,某些高级别的插件,使得 vundle 又“不够用”了。我们知道,大部分 vim 插件都是脚本,但是仍然存在一些插件会自带个 lib(打个广告,鄙人的 vimcaps 也属于这类),那么,如果插件作者释出的是 lib 的源码,或者 lib 依赖于平台需要本地编译,vundle 模式的“东西取下来,加路径”等一坨设定就不够用了,——我们的 lib 要编译过,插件才能用;又或者,很多牛人做了不少插件之后,将其中的某些部分抽取出来,于是插件之间有依赖关系(WTF!),单独 :Plugin 一个插件可能不够,又或者,有人不喜欢 github 而是把东西扔到 bitbucket or somewhere else(目前 vundle 已经支持非 github 的 repo)或者我用的是 svn 呢啊 hg 呢啊……在这些越来越复杂的需求下,人们不满足于 vundle 提供的便利性,(好吧你或许猜到了我要说的是 Shougo 大神升级版 vundle)neobundle 被造了出来。这货既然号称下一代的 vundle,自然比 vundle 要牛 X 一些,比如针对 post install action,neobundle 可直接在 vimrc 中配置动作,更加方便懒人们拿一个 vimrc 扔到机器上稍微初始化下就得到熟悉的工作环境这个需求。然而,这货我没用过,细节之处无法评价。不过鉴于 Shougo 大神的作品质量一直很高,相信这个管理器也不例外。BTW,如果用了 Shougo 大神自己的 vimproc,这货可以异步安装/更新插件。当然,Shougo 大神很谦逊的表示,这个“下一代”可能还不够稳定,追求稳定的同志还请继续使用 vundle。
接下来,鄙人一直在用的插件管理器要登场啦!还记得最开始要你记住的那个名字么?Bingo,vim addon manager,相信你在试着搜索这个名字的时候,Google 给出的应该是我现在提到的这个(by MarcWeber 大神),而不是前面那个 Ruby 的应用 XD。(And 接下来让我们简称它 VAM 吧)
VAM 完全不同于 vundle 及类似物(是的,除了 neobundle 之外,还有其他相似的管理器哦),而且 VAM 灰常庞大,提供了各种至少很炫酷很碉堡的功能例如:按插件名字搜索,插件名称补全,自动解决依赖关系、(一定程度上)自动保存本地修改等等。所以在我看来,一直到 VAM 诞生,vim 才算是有了真正意义上的“插件管理器”,你不再需要在意你要的插件到底是 http://vim.org 上的,github 上的,bitbucket 上的还是 google code 上,不需要关心到底是 git,hg,svn,甚至 http://vim.org 上的 zip,tgz,bz2 甚至 vimball……所有 dirty 的东西统统不用你管,你只需要知道你想要的插件在 VAM 的数据库中叫什么(而且好消息是,MarcWeber、Shougo 等人已经联手弄了个 vim-pi 的数据库方便各种插件管理器共享插件信息),虽然在初期,插件的名字曾经发生过变化(不知道现在稳定下来没有)、插件名称可能不太好记、插件名称区分大小写所以容易弄混……
可是!尽管我是 VAM 用户,不得不说这货灰常庞大复杂,很多高级功能至今我也没弄明白,只是按照我目前的配置,it works 而且 work 的还不错这样。
总结,目前主流比较流行的 vim 插件管理(仅依赖 vim)主要是这四家:Pathogen、Vundle、NeoBundle 和 VAM,最主要需要考虑的几点有:Vundle 的用户相对最多而且使用比较简洁方便;NeoBundle 功能更加强大,可以指定特定版本;VAM 只需要大体上记住插件名字就可以使用,模糊匹配和补全功能,自动解决依赖关系。
与 Ruby/perl 版本的管理器相比,这四家都会改 rtp,从而使得 autoload 延迟加载时 vim 的搜索路径增多(尤其安装的插件多了之后),可能会影响到 vim 的速度。
And 我快写完的时候,找到了这个: topic/vim plugin managment (MarcWeber 大神总结的?应该很全面了)
然后,*nix 平台上有人受不了了,弄过几个独立的第三方插件管理器, 比如这里面有个东东叫 vim addon manager(请记住这个名字 XD) (当然,请原谅我,还有好几个类似的东东我都忘了叫啥了,有谁知道欢迎补充) 。 vam 是 ruby 写的, 看名字就知道丫是干嘛用的 , 不过…… 我没用过它所以没法评价 (曾经“用过”的一个第三方管理器叫 vimana,什么表现嘛我就不记得了)。
但这种第三方的一般都是某种脚本语言写的,在 *nix 上还好,让我们 windows 用户肿么办……然后,有个灰常霸气的东东出现了,——vimball。这货可以看做是 vim 界的 docstrip(其实更简洁),简直是个神器。从此装插件易如反掌,麻麻再也不用担心我不会装插件啦!三个咒:
vim XXX.vba :so % :q
于是这就有了限制。那其他的呢尤其是提供 zip/tarball 的咋办。基于 vimball 修改 runtimepath 的理念,一个更加没有限制的插件“管理器”诞生了,这货叫 pathogen(by tpope 大神)。只需把你的 tarball 整个解到 pathogen 的管理目录(bundle)下,vimrc 稍作处理,这个插件就可以用啦!曾经那个混乱的目录结构 sayonara~~ 插件管理变成文件管理,很方便有木有!
可是,懒惰的人们嫌这个还不够。刚好,github 流行起来,很多 vim 插件的作者都将插件放到 github 上托管。于是有人通过 git module 来管理自己的 vim 插件,以达到“一份 vimrc 走遍天下”的目的,不需要自备 vimfiles 目录。在这个背景下,划时代的插件管理器终于诞生了,这货叫 vundle(by gmarik。顺便提一句,vundle 刚不久前经历了一次大版本升级,主要命令发生了变化,请用户注意)。
vundle 诞生之后,很长时间内这成为了众多 vimmer 的标配(至今仍是),这货一定程度上真正达到了一个 vimrc 搞定一切的“终极”目标,——对大部分插件尤其全部是 vim script 至多依赖 +python/+lua 等的插件而言,vundle 足够方便足够简洁,并且有着足够实用的管理方式:安装、升级、停用、卸载都仅需一条命令,必须是 life changing 的评分。唯一需要的是,你用的插件在 github 上有对应的 repo,或者 http://vim.org 上注册存在,并且你要有个能用的 git。
然后,某些高级别的插件,使得 vundle 又“不够用”了。我们知道,大部分 vim 插件都是脚本,但是仍然存在一些插件会自带个 lib(打个广告,鄙人的 vimcaps 也属于这类),那么,如果插件作者释出的是 lib 的源码,或者 lib 依赖于平台需要本地编译,vundle 模式的“东西取下来,加路径”等一坨设定就不够用了,——我们的 lib 要编译过,插件才能用;又或者,很多牛人做了不少插件之后,将其中的某些部分抽取出来,于是插件之间有依赖关系(WTF!),单独 :Plugin 一个插件可能不够,又或者,有人不喜欢 github 而是把东西扔到 bitbucket or somewhere else(目前 vundle 已经支持非 github 的 repo)或者我用的是 svn 呢啊 hg 呢啊……在这些越来越复杂的需求下,人们不满足于 vundle 提供的便利性,(好吧你或许猜到了我要说的是 Shougo 大神升级版 vundle)neobundle 被造了出来。这货既然号称下一代的 vundle,自然比 vundle 要牛 X 一些,比如针对 post install action,neobundle 可直接在 vimrc 中配置动作,更加方便懒人们拿一个 vimrc 扔到机器上稍微初始化下就得到熟悉的工作环境这个需求。然而,这货我没用过,细节之处无法评价。不过鉴于 Shougo 大神的作品质量一直很高,相信这个管理器也不例外。BTW,如果用了 Shougo 大神自己的 vimproc,这货可以异步安装/更新插件。当然,Shougo 大神很谦逊的表示,这个“下一代”可能还不够稳定,追求稳定的同志还请继续使用 vundle。
接下来,鄙人一直在用的插件管理器要登场啦!还记得最开始要你记住的那个名字么?Bingo,vim addon manager,相信你在试着搜索这个名字的时候,Google 给出的应该是我现在提到的这个(by MarcWeber 大神),而不是前面那个 Ruby 的应用 XD。(And 接下来让我们简称它 VAM 吧)
VAM 完全不同于 vundle 及类似物(是的,除了 neobundle 之外,还有其他相似的管理器哦),而且 VAM 灰常庞大,提供了各种至少很炫酷很碉堡的功能例如:按插件名字搜索,插件名称补全,自动解决依赖关系、(一定程度上)自动保存本地修改等等。所以在我看来,一直到 VAM 诞生,vim 才算是有了真正意义上的“插件管理器”,你不再需要在意你要的插件到底是 http://vim.org 上的,github 上的,bitbucket 上的还是 google code 上,不需要关心到底是 git,hg,svn,甚至 http://vim.org 上的 zip,tgz,bz2 甚至 vimball……所有 dirty 的东西统统不用你管,你只需要知道你想要的插件在 VAM 的数据库中叫什么(而且好消息是,MarcWeber、Shougo 等人已经联手弄了个 vim-pi 的数据库方便各种插件管理器共享插件信息),虽然在初期,插件的名字曾经发生过变化(不知道现在稳定下来没有)、插件名称可能不太好记、插件名称区分大小写所以容易弄混……
可是!尽管我是 VAM 用户,不得不说这货灰常庞大复杂,很多高级功能至今我也没弄明白,只是按照我目前的配置,it works 而且 work 的还不错这样。
总结,目前主流比较流行的 vim 插件管理(仅依赖 vim)主要是这四家:Pathogen、Vundle、NeoBundle 和 VAM,最主要需要考虑的几点有:Vundle 的用户相对最多而且使用比较简洁方便;NeoBundle 功能更加强大,可以指定特定版本;VAM 只需要大体上记住插件名字就可以使用,模糊匹配和补全功能,自动解决依赖关系。
与 Ruby/perl 版本的管理器相比,这四家都会改 rtp,从而使得 autoload 延迟加载时 vim 的搜索路径增多(尤其安装的插件多了之后),可能会影响到 vim 的速度。
And 我快写完的时候,找到了这个: topic/vim plugin managment (MarcWeber 大神总结的?应该很全面了)