In order to install Gist as a plugin, you have to modify its `dir` to be
the `plugin` subdirectory of the normal path of the plugin if it were an
ordinary pathogen-compatible Vim plugin.
Plug 'https://gist.github.com/952560a43601cd9898f1.git',
\ { 'dir': g:plug_home.'/xxx/plugin', 'rtp': '..' }
PlugClean command was incompatible with the above trick, so it was
updated not to remove the parent directory of `dir` of each plugin.
There's a fairly widespread convention which recommends indicating the default
confirmation option in uppercase. Granted, the number of applicable instances
in vim-plug is currently only two, but perhaps this'll save users with such an
inclination having to hit Enter just to sate their curiosities.
In the recent versions of NeoVim, jobstart() does not return
monotonically increasing numbers, this caused vim-plug to miss updating
the progress of a task when the job ID for the task is already
reassigned to a new task.
/cc @andreicristianpetcu
plug#begin expands its path argument and converts it to the absolute
path by default. However, it makes sense to use the unexpanded form in
case of PlugSnapshot as described in
https://github.com/junegunn/vim-plug/issues/97#issuecomment-57421483
For example, for the following cases,
- call plug#begin('~/.vim/plugged')
- call plug#begin('$HOME/.vim/plugged')
PlugSnapshot will use the exact arguments, `~/.vim/plugged` or
`$HOME/.vim/plugged`, instead of the absolute paths such as
`/home/jg/.vim/plugged`.
Related discussion can be found in #83. If the user choose not to use
syntax highlighting, he can disable it by putting `syntax off` after
`plug#end()`. But since `plug#end()` is called by `PlugInstall` or
`PlugUpdate`, it is reenabled on those commands which is not desirable.
This commit fixes the issue by changing `plug#end` to do `syntax enable`
only during Vim startup.
