b763cae81a
plugin directories now appear in the runtime path in the same order they are listed. this allows plugs that depend on other plugins to be loaded after their dependencies. |
||
|---|---|---|
| gif | ||
| test | ||
| plug.png | ||
| plug.vim | ||
| README.md | ||
A single-file Vim plugin manager.
Somewhere between Pathogen and Vundle, but with faster parallel installer.
Pros.
- Easier to setup
- Parallel installation/update (requires +ruby)
- Smallest possible feature set
- Branch/tag support
- On-demand loading
- Dependency resolution using
Plugfile(experimental)
Cons.
- Everything else
Usage
Download plug.vim and put it in ~/.vim/autoload
mkdir -p ~/.vim/autoload
curl -fLo ~/.vim/autoload/plug.vim https://raw.github.com/junegunn/vim-plug/master/plug.vim
Edit your .vimrc
call plug#begin('~/.vim/plugged')
Plug 'junegunn/seoul256.vim'
Plug 'junegunn/vim-easy-align'
Plug 'scrooloose/nerdtree', { 'on': 'NERDTreeToggle' }
" Plug 'user/repo1', 'branch_or_tag'
" Plug 'user/repo2', { 'rtp': 'vim/plugin/dir', 'branch': 'devel' }
" Plug 'git@github.com:junegunn/vim-github-dashboard.git'
" ...
call plug#end()
Reload .vimrc and :PlugInstall to install plugins.
Plugin directory
If you omit the path argument to plug#begin(), plugins are installed in
plugged directory under the first path in runtimepath at the point when
plug#begin() is called. This is usually ~/.vim/plugged (or
$HOME/vimfiles/plugged on Windows) given that you didn't touch runtimepath
before the call.
Commands
| Command | Description |
|---|---|
| PlugInstall [#threads] | Install plugins |
| PlugUpdate [#threads] | Install or update plugins |
| PlugClean[!] | Remove unused directories (bang version will clean without prompt) |
| PlugUpgrade | Upgrade vim-plug itself |
| PlugStatus | Check the status of plugins |
Options for parallel installer
| Flag | Default | Description |
|---|---|---|
g:plug_threads |
16 | Default number of threads to use |
g:plug_timeout |
60 | Time limit of each task in seconds |
Example: A small sensible Vim configuration
call plug#begin()
Plug 'tpope/vim-sensible'
call plug#end()
On-demand loading of plugins
" NERD tree will be loaded on the first invocation of NERDTreeToggle command
Plug 'scrooloose/nerdtree', { 'on': 'NERDTreeToggle' }
" Multiple commands
Plug 'junegunn/vim-github-dashboard', { 'on': ['GHDashboard', 'GHActivity'] }
Dependency resolution
Articles
FAQ/Troubleshooting
Plugins are not installed/updated in parallel
Your Vim does not support Ruby interface. :echo has('ruby') should print 1.
In order to setup Vim with Ruby support, you may refer to this
article.
Vim: Caught deadly signal SEGV
If your Vim crashes with the above message, first check if its Ruby interface is working correctly with the following command:
:ruby puts RUBY_VERSION
If Vim crashes even with this command, it is likely that Ruby interface is
broken, and you have to rebuild Vim with a working version of Ruby.
(brew remove vim && brew install vim or ./configure && make ...)
If you're on OS X, one possibility is that you had installed Vim with Homebrew while using a Ruby installed with RVM or rbenv and later removed that version of Ruby.
Please let me know if you can't
resolve the problem. In the meantime, you can set g:plug_threads to 1, so that
Ruby installer is not used at all.
Errors on fish shell
If vim-plug doesn't work correctly on fish shell, you might need to add set shell=/bin/sh to your .vimrc.
Refer to the following links for the details:
- http://badsimplicity.com/vim-fish-e484-cant-open-file-tmpvrdnvqe0-error/
- https://github.com/junegunn/vim-plug/issues/12
Freezing plugin version with commit hash
vim-plug does not allow you to freeze the version of a plugin with its commit hash. This is by design. I don't believe a user of a plugin should be looking at its individual commits. Instead, one should be choosing the right version using release tags or versioned branches (e.g. 1.2.3, stable, devel, etc.)
Plug 'junegunn/vim-easy-align', '2.9.2'
If the repository doesn't come with such tags or branches, you should think of it as "unstable" or "in development", and always use its latest revision.
If you really must choose a certain untagged revision, consider forking the repository.
Regarding feature request
You may submit a request for a new feature by creating an issue. However, please be minded that this is an opinionated software and I want to keep the feature set as small as possible. So I may not agree with you on the necessity of the suggested feature. If that happens, I suggest the following options.