index edit log

plugin management

dev topic: vipi: vipi.

Traditionally plugins were mantained manually by extracting files into $HOME/.vim. Wrong about this approach is that its hard to maintain because its you having to keep track about which files belong to each plugin. :h plugin tells you about this traditional way.

Little bit smarter is creating a directory for each plugin like this and adding two lines to your .vimrc:

  " vimrc
  set runtimepath+=~/.vim/plugin-A
  set runtimepath+=~/.vim/plugin-B

This tells Vim that it should look for plugin files to source at startup in additional directories. What's wrong about this? Nothing except for example vim does not source plugin-A/plugin/after/*.vim files.

Pathogen does exactly this by its pathogen#infect and provides some more helper functions to run helptags etc

Vundle was also written to checkout plugin from git repositories

So both Vundle and Pathogen get the job done pretty well which is why they are referenced often.

VAM/vim-addon-manager also tries to help you avoiding outdated plugins by introducing a pool of known plugins.

VAM, Pathogen, Vundle, GetLatestVimScripts, Vimpire, Vimana, jolt, vim-nicktears, Vim Srcipt Updater, Npackd, |vim-flavor, NeoBundle, vizardry, |voom comparison:
featureVAMPathogenVundleGetLatestVimScriptsVimpireVimanajoltvim-nicktearsVim Srcipt UpdaterNpackd|vim-flavorNeoBundlevizardry|voomfeature description
rtpyesyesyesyesyesmanipulate the runtimepath
rtp-afteryesyesyesyesyestakes care about after/* files
activate plugins at runtimeyesyesyesActivating plugins at runtime allows you to load ruby related plugins when you open a .rb file. This also means you could load a plugin when pressing a key such as % to load matchit.
plugin name completionyescompletes plugin names in .vim files
bootstrap from .vimrcyesyou can write this code for the other managers easily
updating pluginsyesyesyesyes
install progress baryesyes
dependencies in package descriptionyesyesminimal dependency support
dependencies in vimrcyesminimal dependency support
get-gityesyesyesyesinstall from git repositories
get-hgyesyesyesinstall from mercurial
get-svnyesyesyesinstall from svn
get-bazaaryesyesyesinstall from svn
get-vim.sf.netyesyesyesinstall from
bisectyesbisect problems by dividing the set of plugins to be activated
ships-with-vimyesDoes the Vim distribution contain it?
asynchronous update installyes
?yesyesyesyesyesyesyesyesdon't know it well enough, help fill in information
supports uniteyesHow tight the integration is have a look at the plugin's documentation
revision lockyesrevision lock can be emulated by putting your .vim into a repository (hg/git/..) using almost any plugin manager (?)
helptags-on-installyesyesThis means :help is likely to do what you expect it to do without running helptags on each startup and without caring.
manual-helptagsyesyesyesProvides command to run :helptags conveniently

Also see neobundle-vs-vam-merge.

viml vs other

Other means something like python pip, ruby gems and the like. What's the main difference?

viml, other comparison:
featurevimlotherfeature description
bootstrappingyesbootstrapping from .vimrc easily possible. Eg you patch the pool in .vimrc, you copy you'r .vimrc and you're done
reusing existing package managersyes

Example .vimrc setups

Pathogen: vimrc:

" you can tell pathogen which directories to infect
" this way it may also be possilbe to select "sets of plugins"
execute pathogen#infect()

Vundle: vimrc:

set rtp+=~/.vim/vundle.git/ 
" These refer to git repositories:
Bundle 'gmarik/vundle'
Bundle 'tpope/vim-fugitive'
Bundle 'rstacruz/sparkup', {'rtp': 'vim/'}


vim-plugins.file (this could be implemented by all plugin managers):

# By topic, see tag_regex below
{'name': 'plugin_c', 'tag': 'c-dev'}
{'name': 'plugin_ruby', 'tag': 'ruby-dev'}

# These will be loaded always
{'name': 'foo', 'type':'git', 'url': 'github:....', 'at-git-hash': '...'}

# This will be loaded when you open .php files:
{'name': 'script-php', 'ft_regex':'^\.php$'}

# Additional keys such as "at-git-hash: CFE94A" could be implemented trivially


  " Code omitted checking out VAM and setting runtimepath. See VAM's Readme
  call vam#Scripts("vim-plugins.file", {'tag_regex': 'c-dev\|ruby-dev'})
  " or
  VamActivate plugin-name1 plugin-name2

at runtime (activate plugins lazily when you need them):

  " most useful commands supporting tab completion:

  " fetch and activate at runtime (alias for vam#ActivateAddons)
  :ActivateAddons name1 name2 

  " show infos about name/script-id
  :AddonsInfo name

VAM does not implement "versioning" yet because the author does not get payed for working impleminting such features. It tries to provide 80% of a perfect result by spending only 20% of effort. Marc Weber doubts that versioning is worth it given that the amount of ways you can combine packages is much larger than the Vim community can test which is why VAM propagates "use latest" versions. You could implement "git submodule" support yourself or talk to the VAM team to make them add some post/processing features for install/updates managing git submodules. However this would also require allowing VAM to install git based repositories only?

Vim Flavor I've contacted the author to see how VAM and that project can collaborate (eventually only no the pool of plugins?).

This mainly wants to use the existing ruby gem packaging system to manage Vim plugins in some way.

NeoBundle Examples from mail by Marcel Boon, date: December 27 2013 11:25AM illustrating some features:

Automatic compiling:
NeoBundle 'Shougo/vimproc', {
            \ 'build' : {
            \     'windows' : 'make -f make_mingw32.mak',
            \     'cygwin' : 'make -f make_cygwin.mak',
            \     'mac' : 'make -f make_mac.mak',
            \     'unix' : 'make -f make_unix.mak',
            \    },
            \ }

Loading only on a specific command or filetype:
NeoBundleLazy 'thanthese/Tortoise-Typing', { 'autoload' : {
            \ 'commands' : 'TortoiseTyping'
            \ }}
NeoBundleLazy 'mattn/emmet-vim', {'autoload':
            \ {'filetypes': ['html', 'xhttml', 'css', 'xml', 'xls', 'markdown']}}

Dependecy handling:
NeoBundleLazy 'xolox/vim-lua-ftplugin' , {
            \ 'autoload' : {'filetypes' : 'lua'},
            \ 'depends' : 'xolox/vim-misc',
            \ }



    ScriptID SourceID Filename
    294 1 :AutoInstall: Align.vim
    120 2 Decho.vim
     40 3 DrawIt.tar.gz
    451 4 EasyAccents.vim
    195 5 engspchk.vim
    642 6 GetLatestVimScripts.vim
    489 7 Manpageview.vim


  " optional
  let g:GetLatestVimScripts_allowautoinstall=1
  " or run :GLVS

vizardry: Tries to be simple. A simple :Scry snipmate search illustrates its potential problems, the result is (2013-02-14):

    :Scry snipmate leads to:

    0: msanders/snipmate.vim
    (snipMate.vim aims to be a concise vim script that implements some of TextMate's snippets features in Vim. )

    1: honza/vim-snippets
    (vim-snipmate default snippets (Previously snipmate-snippets))

    [.. some more omitted ..]

The point is: Upstream is garbas/snimpate (and you're very likely to miss that ending up asking on #vim for support) - and people will tell you "use garbas/snipmate" which would have been the solution provided by VAM.

I only did this one search - hoping that its representative. :/

A second search :Scry commenting is missing which at least Marc Weber considers to be the most simple yet somewhat featureful solution.

Npackd: Its a package manager for Windows which happens to contain some Vim plugins. Pathogen, VAM etc can be used to load the plugins.


exec ':source ' . $ALLUSERSPROFILE . '/Npackd/VimPlugins/vim-pathogen/autoload/pathogen.vim'
execute pathogen#infect($ALLUSERSPROFILE . '/Npackd/VimPlugins/{}')

VAM will provide a xml source file for all plugins. Npackd support .bat files which can be used to git/mercurial/... on Windows in the future in some way.

voom: depends on pathogen, its a simple shell script reading a text file running git clone

supporting git only - is it a problem ?

Now it might look that being able to install from git repositories only is a major disadvantage. Its not because there is mirroring plugins in git repositories.

Please note that vim-srcipts does not disambiguate names related vim-scraper issue Test yourself: |search for rpl (after the slash there is an input), then click on all 3 rpl plugins which get linked to the same github page! This is a bug.

plugin dependencies

Right now VAM is the only plugin manager which introduces a addon-info.json file (which could be used by other tools) which allows to specify dependencies by name (without version constraints). Those plugins are installed and activated automatically.

git submodules

They are used to embed git repositories into existing git repositories. Thus style is used to reproduce the exact behaviour on a new machine. It can be used with any plugin manager - as long as plugins are checked out by git.

windows support

Well, most plugins should work fine - however installing all dependencies (git, mercurial, unzip, ...) can be tedious (VAM case). See, VAM docs, section 10

This could be simplified - there was no need to do so yet.



additional solutions and in some way related projects

vimapt (I don't know much about it yet)

vimpyre: A python package managing vim scripts somehow. Its using pathogen to manage loading of the scripts:


another list:

There is another project called vim-addon-manager for debian, see debian's vim-addon-manager


How to support all plugin managers While "giving freedom" is nice its not how the world works. We should join efforts to address the real in-which-way-does-vim-suck rather then asking users and authors to compare 10 plugin managers IMHO.

dependencies and prerequisites

Some plugins are not 'viml' only, they need additional tools libraries or whatsoever.

There are two ways of installation: unattended automatic installations. Examples are gentoo portage, nix and more. Here its important that tools can be written writing supporting code (such as gentoo ebuilds, nix derivations), they they eventually must even know in advance which kind of dependencies are requires, such as python pypi libraires. But even then its not trivial to find out how those dependencies should be forwarded to Vim, because even two different plugins could depende on different python versions of the same python library (or python 2 vs python 3 version) - for those reasons Marc Weber is not sure whether its worth bothering about all details - and whether its our task - or gentoos task - or the task of the plugin maintainaer etc. Who should be responsible? Which is least effort?

This is a short list about plugins and kind of dependencies they have so that we can think about how to support this in the sanest way for vim-pi.

vim-addon-async, vimproc comparison:
featurevim-addon-asyncvimprocfeature description
requires-gccyesgcc compiler required (this is not accurate, what about win vs linux, posix etc?)
info-neededyespeople knowing these plugins should add features and finish this description