“VAM” is short name for vim-addon-manager. You declare a set of plugins. VAM will fetch & activate them at startup or runtime depending on your needs. Activating means handling runtimepath and making sure all .vim file get sourced. The FEATURES to learn more.

This screenshot shows:

• The log buffer
• The plugin name completion
• That vim-pi knows about plugins which are neither known by vim-scripts.org nor by vim.sf.net (marked by NA)

then you may also want to have a look at vim-git-wiki.

VAM is well supported by at least 2 maintainers. Try github tickets or Vim irc channel on freenode.

VAMActivate after startup does load plugin/**/*.lua files. lazy.nvim plugin manager might be worth looking at, too

A plugin is set of files having Vim's rtp directory layout (plugin/, ftplugin/, ...). It is identified by name which will be looked up by vim-pi or a url such as git:url, github:user/repo, ...

Plugin names can be found by using completion in .vim files. VAMActivate & VAMPluginInfo commands also offer name completion by or .

In most cases you activate plugins by using its name. Wrapping the name in a dictionary {'name': 'name'} allows attaching additional information which could be used by checkout functions ...

set nocompatible | filetype indent plugin on | syn on
set runtimepath+=/path/to/vam
call vam#ActivateAddons([PLUGIN_NAME])

This setup will checkout VAM and all plugins on its own unless they exist:

" put this line first in ~/.vimrc
set nocompatible | filetype indent plugin on | syn on

fun! SetupVAM()
  let c = get(g:, 'vim_addon_manager', {})
  let g:vim_addon_manager = c
  let c.plugin_root_dir = expand('$HOME', 1) . '/.vim/vim-addons'

  " Force your ~/.vim/after directory to be last in &rtp always:
  " let g:vim_addon_manager.rtp_list_hook = 'vam#ForceUsersAfterDirectoriesToBeLast'

  " most used options you may want to use:
  " let c.log_to_buf = 1
  " let c.auto_install = 0
  let &rtp.=(empty(&rtp)?'':',').c.plugin_root_dir.'/vim-addon-manager'
  if !isdirectory(c.plugin_root_dir.'/vim-addon-manager/autoload')
    execute '!git clone --depth=1'
        \       'https://github.com/MarcWeber/vim-addon-manager'
        \       shellescape(c.plugin_root_dir.'/vim-addon-manager', 1)
  endif

  " This provides the VAMActivate command, you could be passing plugin names, too
  call vam#ActivateAddons([], {})
endfun
call SetupVAM()

" ACTIVATING PLUGINS

" OPTION 1, use VAMActivate
VAMActivate PLUGIN_NAME PLUGIN_NAME ..

" OPTION 2: use call vam#ActivateAddons
call vam#ActivateAddons([PLUGIN_NAME], {})
" use <c-x><c-p> to complete plugin names

" OPTION 3: Create a file ~/.vim-scripts putting a PLUGIN_NAME into each line (# for comments)
" See lazy loading plugins section in README.md for details
call vam#Scripts('~/.vim-scripts', {'tag_regex': '.*'})

Give the downloader a try if you're too lazy to install supporting tools. In the doc/ directory you'll find additional information. https (self signed certificate) can be used, too.

" Note: All commands support completion (<c-d> or <tab>)

" install [UE] without activating for reviewing
VAMInstall PLUGIN_NAME PLUGIN_NAME

" install [UE], then activate
VAMActivate P1 P2 ...
VAMActivateInstalled (same, but completion is limited to installed plugins)

" find plugins by name github url or script id and display all information
VAMPluginInfo script_id or characters to match any description against

" update plugins (by name or all you're using right now) - you should restart Vim afterwards:
VAMUpdate vim-pi P1 P2
VAMUpdateActivated

VAMListActivated
VAMUninstallNotLoadedPlugins P1 P2

" [UE]: unless the directory exists
" P1 P2 represents arbitrary plugin names, use <c-x><c-p> to complete in .vim files

" If you need a plugin to be activated immediately. Example: You require a command in your .vimrc:
call vam#ActivateAddons(['P1', P2'], {'force_loading_plugins_now': 1})
" (should we create a special command for this?)

Also: Of course VAM allows using subdirectories of repositories as runtimepath. Eg See vim-pi-patching.

You can tag plugins and load them lazily. If a plugin provides a 'au BufRead,BufNewFile set ft..' like code fource buftype by adding a key such as {'exec':'set ft=tss'} for instance

let scripts = []
call add(scripts, {'names': ['plugin_for_c_1', 'plugin_for_c_2'], 'tag': 'c-dev'})
call add(scripts, {'name': 'plugin_ruby', 'tag': 'ruby-dev'})
" must activate by filename because .pov filetype is known after the script
" script-povray got activated
call add(scripts, {'name': 'script-povray', 'filename_regex':'\.pov$'})
" for others ft_regex can be used:
call add(scripts, {'name': 'script-php', 'ft_regex':'^\.php$'})

" always activate this color scheme, and set runtimepath
call add(scripts, {'name': 'github:daylerees/colour-schemes', 'addon-info': {'runtimepath': 'vim'} })

" just activate a rtp (also works at runtime with all hooks such as sourcing ftdetect/*.vim files)
call add(scripts, {'activate_this_rtp': 'absolute-rtp-path'})


" tell VAM about all scripts, and immediately activate plugins having the c-dev tag:
call vam#Scripts(scripts, {'tag_regex': 'c-dev'})

" activate all tagged scripts immediately
call vam#Scripts([], {'tag_regex': '.*'})

Instead of adding dictionaries to a local list you can make VAM read them from a file as show at vim-wiki's plugin management article

Having a declarative list of plugins you might be using allows

• implementing a garbage collector
• implementing third party update/checkout scripts which run checkout in parallel
• reusing such interface by other plugin managers

Plugins ship with addon-info.json files listing the dependencies as names (eventually with source location). Those who don't get patched by vim-pi.

Only mandatory dependencies should be forced this way. Optional dependencies should still be installed/activated by you.

NOTE: VAM is declarative. Thus Bundle behavel like VAMActivate:

1. checkout plugin unless directory exists
2. activate it Thus there is no reason to run BundleInstall or such (what for anyway?)

set rtp+=~/.vim/bundle/vim-addon-manager/
call vundle#rc()
Bundle fugitive
VAMActivate by-name-and-pull-depenedencies

Emulation is not complete yet. If you want us to complete it (eg implement the second {rtp: ..} create a github issue. Its obsolete, because vim-pi is very likely to know about it if you install by name.

• by skimming this README.md file
• by looking at headlines at doc/*getting-started.txt. (Note: this is best read in Vim with :set ft=help)

• Declarative: The behaviour of Vim is determined by your .vimrc only. [1]
• Automatic runtimepath handling: install/ update/ use manually installed addons on startup or load them lazily as needed when you feel that way. [3]
• Builtin dependency management. [2]
• Based on a pool of addons which is maintained by the community. This allows warning you if you’re going to install outdated packages. Of course you can opt-out and use your own pool easily.
• Sources from www.vim.org, git, mercurial, subversion, bazaar, darcs, [...]
• Addon name completion in .vim files and :(Update|Activate)Addons commands.
• Short syntax for github repos: github:name/repo.
• Optionally writes update logs.
• Cares about windows users.
• Addon info by name or script id (:AddonInfo).
• Tries to preserve user modifications by using diff/patch tools on unix like environments (for non-version-controlled sources).
• 100 % VimL (is this really that good?..)
• The VimL code which gets started each time is contained in one file: vam.vim (700 loc). Everything else has carefully been put into additional supporting files.

[1]: assuming you always use latest versions

[2]: this serves the community by making it easy to reuse other’s code. Implemented by a addon-info.json file and patchinfo database for addons without VAM support.

[3]: Yes — there are some special cases where it does not work correctly because some autocommands don’t get triggered

[4]: Plugin authors should use addon-info file instead. patchinfo.vim is for addons not supporting VAM.

Here you go:

• GETTING STARTED
• additional docs

It’ll never have nice install progress bars — because the “progress” is not very well known because addons can be installed at any time — and additional dependencies may be encountered.

If you want to be able to rollback you have to use git submodules yourself or find a different solution — because VAM also supports other VCS and installing from archives. We have implemented experiemntal setup, but because VAM may add additional files such as addon-info.json in some cases repositories look dirty usually.

VAM does not support parallel installation yet (Like NeoBundle) - we think dependencies are more important. If you feel strongly about this create a issue. This would require rewriting quite a lot of code.

Each call of VAMActivate takes about 1ms - if that's too much pass many plugin names at once.

VAM suffers from installing one plugin after the other which is slowing down. It should install in parallel/in the background. Some plugins like YouCompleteMe might even depend on the Python interpreter to be used (conda env)

Not all people use VAM. VAMActivate can be used on demand. So how should this all move into the future? using neovim's async/await? or sync'd install allowing users to 'plug' or whatever install a plugin?

install_activate_plugin_wait('github:foo/bar') install_activate_plugin('github:foo/bar', clb) user could choose whether he wants to be asked before getting new code and activate it - there could be security issues.

Then people could use the plugin manager they want and locations they want and they could rewrtite foo/bar by baz/bar if there is need ?

[... TODO ... ]

A totally different approach would be a cross language/cross platform package manager with a declarative dependency file {"requires": [...]} like. Then an external tool could be taking care of. Then updating all would be like conda ..

This would also allow linux systems to package everything automatically. So I somewhat like this idea

vim-wiki's list of alternatives

debian’s vim plugin manager The author (Jamessan) is fine with this project sharing the same name.

vundle Referencing it here because gmarik taught us how important it is to have both: A simple nice user interface and a short descriptive, complete README.md - Other managers see link above.