I want to know how do you manage your vim plugins.
As it is,
One of the biggest fun of using is that one can easily try many interesing new plugins, just download it and unzip it in under ~/.vim
. But if you try too often and try too much, you might get trouble as confilct of key mapping , in compatitble script version, dpendency between different plugin .....
Then you want to remove some plugin ,kind of like rollback your vim to a sound condition. But, the rollback coul开发者_运维知识库d be very painful . cus for some "giant" plugin, like perl-support ( it's great plugin, anyway), will consist of many vim scripts which spread in different dirctories. To remove single one giant plugin will be anoying, not too mention if you remvoe many plugin at one time.
In a word , I'm looking for good practice for managing vim plugins.
I have my vim directory in git.
All plugins that have an upstream public git repo are in ~/.vim/plugins-git/
as git submodules. My vimrc
sets the runtimepath to include the directories in ~/.vim/plugin-git/
so the plugins can stay self contained and can very easily be updated to the latest git commit.
The rest of my plugins are in ~/.vim/plugin/
.
One script that's out there that makes this type of setup much easier is pathogen.vim. pathogen.vim sets up all the runtimepath entries for you so you don't have to. It's worth looking into for sure. I don't use pathogen because by setting the paths explicitly in my vimrc
I can quickly disable plugins if there are conflicts or incompatibilities like you mentioned.
Vundle definitely deserves a mention, as it makes vim plugin management ridiculously simple.
1. git clone https://github.com/gmarik/vundle.git ~/.vim/bundle/vundle
2. open up your vimrc
3. Add your plugins (Bundle '<link to plugin>') <-- look at the example vimrc on Vundle github page
4. :BundleInstall
I think Vundle was inspired from tpope's Pathogen plugin.
I like vim-addon-manager because it allows me to activate or deactivate a plugin by putting or removing it from the list of active plugins, which eases testing new plugins.
I versionning my vimconfig directory in github. So If I add a plugin I made a new commit. If I want remove it, I revert this commit.
After I link .vimrc in vimrc file in my directory and my .vim directory to this directory
I exclusivley install plugins via Vimballs. This way I can also keep plugins up-to-date across installations.
What I like about vimballs is that I can see directly where files came from. Otherwise I would probably something like git
.
I'm working mostly on Windows, so this may differ somewhat for Linux, Unix and co. but if you help vimfiles you'll see that vim has an order of loading files. First comes the ones in $HOME directory (somewhere under Documents and Settings-Username on WinXP machines), then come the $VIM directory (your actual directory where vim resides) and so on ...
So, I have vim in a directory which consists of "stable" stuff. Whenever I wish to try out a new plugin, I put it in Documents and Settings... folder, and it gets loaded before the one in $VIM directory. That way I can easily upon not liking it, delete the new plugin. If I do like it, and it plays nicely with the ones I already have, it goes in the $VIM directory.
(this probably makes no sense the way I put it, but it works ... probably :)
- Synchronizing plugins with git submodules and pathogen
The pathogen plugin makes it much easier to manage plugins in my case I use with Mercurial. To plugins vimball stile:
:usevimball ~/.vim/bundle/bundle-dir-name-here
see :h :usevimball
I personally use this mappingmanager exactly for the same reasons. (it allows you to switch between mappings easily)
demo: http://playterm.org/r/vim-mappingmanager-plugin-1318246417
download: http://vim.sourceforge.net/scripts/script.php?script_id=3768
精彩评论