TL;DR Use :h packages
You will need
- the plugin code (github is easiest, though if you just have a copy of the
source tree lying around, that works too)
A brief history of time managing plugins1
I won't go into extreme detail here unless it is requested. This is mostly a
background section, and can be skipped if needed.
In the dark ages, you used to need to put all plugin code next to each other, so
(for example) your ~/.vim/plugin
would have
plugin-a.vim
unrelated-plugin-b.vim
- etc.
Updating and removing plugins was a nightmare: what did you do if an update
removed a file? How did you know which files belonged with which plugins and
needed deletion?
Pathogen gave us bundle
to keep things separate, and that's what packages do
too2.
Pathogen (typically) adds each directory under, e.g., ~/.vim/bundle
to the
'runtimepath'
. In other words, you could have
~/.vim/bundle/mypluginhere
, and
~/.vim/bundle/pangloss-javascript-here
But you still managed those directories yourself. (Other plugin managers can do
that for you, but you don't need—or always want—that).
The advantage of this is described Plugin layout in the Dark
Ages and A New
Hope: Plugin Layout with
Pathogen.
Packages bring to vim8 what pathogen had already done for previous vim versions,
and they do so natively. Packages provide a way of adding segmented components
to the 'runtimepath'
(remember that this path controls where vim looks for
plugin code, autoload scripts, filetype plugins, &c.).
Enter packages
Packages use 'packpath'
, which is a bit like a combination of bundle
and
'runtimepath'
.
What you need to know is that you can put a complete copy of the plugin source
tree in ~/.vim/pack/<any-name-you-want>/start/<plugin-name>
. (The adept user
may want to investigate opt
as well.)
That's it. It will be loaded for you by vim.
Some management strategies with git
git-clone
: this strategy is for users who just want to clone the plugin and
have it run. Typical interaction looks like
# git clone <path/to/repo> ~/.vim/pack/<other-plugins>/start/<plugin-name>
git-submodule
: this strategy is for folks like me who keep their
dotfiles/vim configs in version control. Typical interaction looks like
# git -C <dotfile-dir> submodule add <path/to/repo> <dotfile-vim-dir>/pack/<other-plugins>/start/<plugin-name>
- I omit all plugin managers except pathogen, which is actually a
'runtimepath'
manager. This little lie won't hurt anyone, though.
- They have a slightly broader use case. I'm aware, but I don't find it
necessary for the purposes of this question.