Find file
Fetching contributors…
Cannot retrieve contributors at this time
347 lines (267 sloc) 13.2 KB
= plugin management =
**dev topic: vipi**: [[topic/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
**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.
rtp:: manipulate the runtimepath
rtp-after:: takes care about after/* files
activate plugins at runtime:: Activating 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 completion:: completes plugin names in .vim files
bootstrap from .vimrc:: you can write this code for the other managers easily
updating plugins::
install progress bar::
dependencies in package description:: minimal dependency support
dependencies in vimrc:: minimal dependency support
get-git:: install from git repositories
get-hg:: install from mercurial
get-svn:: install from svn
get-bazaar:: install from svn install from
bisect:: bisect problems by dividing the set of plugins to be activated
ships-with-vim:: Does the Vim distribution contain it?
asynchronous update install::
?:: don't know it well enough, help fill in information
supports unite:: How tight the integration is have a look at the plugin's documentation
revision lock:: revision lock can be emulated by putting your .vim into a repository (hg/git/..) using almost any plugin manager (?)
helptags-on-install:: This means :help is likely to do what you expect it to do without running helptags on each startup and without caring.
manual-helptags:: Provides command to run :helptags conveniently
VAM:: rtp, rtp-after, get-git, get-hg, get-svn, get-bazaar,, activate plugins at runtime, plugin name completion, bootstrap from .vimrc, updating plugins, dependencies in package description, bisect, vundle-compatibility, helptags-on-install
Pathogen:: rtp, rtp-after, manual-helptags
Vundle:: rtp, rtp-after, get-git, install progress bar, activate plugins at runtime, manual-helptags, helptags-on-install
GetLatestVimScripts::, updating plugins, dependencies in package description, ships-with-vim
[[|Vimpire]]:: get-hg ?
[[|Vimana]]:: ?
[[|jolt]]:: ?
[[|vim-nicktears]]:: ?
[[|Vim Srcipt Updater]]:: ?
[[|Npackd]]:: get-git, get-hg, get-svn, get-bazaar,, updating plugins, dependencies in packages description, install progress bar
[[||vim-flavor]]:: ?
[[|NeoBundle]]:: ?, rtp, activate plugins at runtime, dependencies in vimrc, asynchronous update install, supports unite, revision lock, get-git, get-svn, get-hg, vundle-compatibility, rtp-after, updating plugins, get-bazaar, manual-helptags
[[|vizardry]]:: rtp, rtp-after, ?
[[||voom]]:: ?
Also see [[topic/neobundle-vs-vam-merge]].
== viml vs other
Other means something like python pip, ruby gems and the like.
What's the main difference?
bootstrapping:: bootstrapping from .vimrc easily possible. Eg you patch the pool in .vimrc, you copy you'r .vimrc and you're done
reusing existing package managers::
viml:: bootstrapping
other:: reusing existing package managers
== Example .vimrc setups ==
" you can tell pathogen which directories to infect
" this way it may also be possilbe to select "sets of plugins"
execute pathogen#infect()
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.
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
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.
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.
depends on pathogen, its a simple shell script reading a text file running git
== 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.
== collections ==
== 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]]
== links
[[|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 [[topic/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
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.
requires-gcc:: gcc compiler required (this is not accurate, what about win vs linux, posix etc?)
info-needed:: people knowing these plugins should add features and finish this description
vim-addon-async:: requires-gcc
vimproc:: info-needed