Use vim-plug over vundle

[geoffharcourt]

vim-plug has a number of advantages over Vundle:

• Installs and updates plugins very quickly in parallel
• Can lock plugins at versions/tags (useful for plugin development)
• Can rollback updates (useful if a plugin breaks) and take/reload snapshots of current plugin state
• Optionally lazily-load plugins when their relevant command is invoked to speed vim start time
• Execute post-update hooks for plugins with compiled extensions, etc.

vim-plug uses a DSL very close to Vundle's (simplest form is Plug vs. Plugin), and here it is set to continue to use the same plugin location that Vundle was using before.

After updating, users will need to

1. Rename Plugin lines in .vimrc.bundles.local to use Plug
2. Run :PlugInstall (the post-up hook does this automatically)

I am unsure of whether automating renaming in .vimrc.bundles.local in a one-time post-up hook (executing it if vim-plug isn't installed at the same time as installing vim-plug) is a good thing to do. For now I've left it out, but if that's needed for widespread support, that would be straightforward to add.

[rspeicher]

👍 I was just thinking about this today.

I'm also interested in the on-demand loading of plugins that Plug can do, but I see you didn't add any of those yet.

[geoffharcourt]

@tsigo, I'm excited about this feature, but I don't think many of the plugins included in .vim.bundles are great candidates for lazy loading. Syntastic, which is one of the longest to load of the base plugin set (on my machine at least), is going to get used for almost every kind of file and gets run whenever a buffer is opened, so lazy loading doesn't help much there.

vim-rails was my top candidate, but it turns out to have a fairly short load time, and has so many relevant commands that I think some would fall through in an attempt to defined the ones that result in pre-loading. I also haven't tested whether vim-rails' awareness of whether you are in a Rails app or not would be affected by being loaded lazily.

Since this commit could potentially disrupt users' plugin use (one time) with the required renaming of plugin declarations, I'd like to keep the changes as compact as possible, and we can start investigating which plugins work well in lazy loading in a later PR.

[geoffharcourt]

Vundle has two plugin options. name and rtp, that can be mapped to vim-plug's dir and rtp.

• rtp is a direct mapping
• name changes the name of the directory within the bundle folder, used to resolve naming conflicts. vim-plug allows custom directory locations anywhere.

This function and custom command should allow users to continue with their existing Plugin "myrepo/myplugin" setup in vimrc.bundles.local, allowing users a smoother upgrade path:

UPDATE: edited this shim in the commit, it's not quite correct.

function! PluginToPlug(arg, options)
  let vundle_options = a:options
  let vim_plug_options = {}

  if len(vundle_options) > 0
    if has_key(vundle_options, 'name')
      let vim_plug_options.dir = "~/.vim/bundle/".vundle_options.name
    endif

    if has_key(vundle_options, 'rtp')
      vim_plug_options.rtp = vundle_options.rtp
    endif
  endif

  Plug a:arg, vim_plug_options
endfunction

com! -nargs=+  -bar Plugin call PluginToPlug(<args>)

[croaky]

I installed vim-easy-align today and noticed that the README recommended vim-plug. Seems like it's gaining some community momentum?

https://github.com/croaky/dotfiles/commit/1efd070ef59d3e8a33e2a6bad223bd0b766dcb43

[rspeicher]

I installed vim-easy-align today and noticed that the README recommended vim-plug. Seems like it's gaining some community momentum?

Well, in that case it's because it's from the same author. I've seen it used/recommended in a few other places though.

[geoffharcourt]

After using this for a couple weeks (during which I've been swapping some experimental plugins in and out), I have had a very nice experience using vim-plug. I think some other folks should also give it a try. @gylaz, should I commit the above-pasted shim-function so that folks don't have to edit their own .vimrc.bundles.local to try?

[gylaz]

What's the impact to existing users of this switch? Do they need to do anything?

[geoffharcourt]

(note: just fixed the shim after doing a little more testing)

I squashed the shim in on the reasoning that it's better to have the easiest migration path possible.

With my .vimrc.bundles.local using Vundle-style Plugin declarations with Vundle's relevant options (name and rtp), I was able to migrate without needing to perform any bootstrapping such as running rcup or any vim commands. Once users pull the new commit down, they should be good to go.

Given that this will cause a lot of error messages on vim start if there's a problem, I'd appreciate it if a few folks could test locally on their machines. The best way to test the migration path would be:

1. Switch to the pr branch, don't edit local dotfiles' .vimrc.bundles.local
2. Start vim, check for any errors
3. (optionally) edit .vimrc.bundles.local to finish the migration

Unless/until Vundle changes their API, we can leave the shim in place. If at some future point Vundle changes their API, I think it would be best to remove the shim after users had gotten time to migrate their .vimrc.bundles.local files.

[derekprior]

The lock and rollback certainly seem interesting enough to consider this. The rest of the stuff... meh.

As for the shim, I think it'd be useful if it outputted a deprecation notice when it was used. Is that possible? We don't want to maintain this shim forever.

Still not certain its the way to go. Why cant these things be added to vundle?

[geoffharcourt]

@derekprior, gmarik wrote last year that he's no longer going to contribute to Vundle. Since April, development has more or less stopped despite lots of open issues and pull requests. The git tag/branch functionality is on Vundle's wishlist, but there are as yet no plans to do lock/rollback.

I'm happy to add a deprecation notice, I think that's the most practical way to get users to update their .vimrc.bundles.local.

[jferris]

If Vundle is basically defunct, I think it makes sense for us to switch to something which is actively developed.

[junegunn]

Hi, I just stumbled upon this :) filetype off here and filetype on below are not required as they are already handled by plug#begin() and plug#end().

[BlakeWilliams]

I just migrated from vundle to vim-plug and it was pretty seamless. I didn't even have to remove my previous bundle directory.

[geoffharcourt]

I just squashed my commits and rebased against master since there have been some changes there since this PR got started.

[geoffharcourt]

I accidentally deleted the branch on Github, which screwed up this PR. Reopened as #368.

[Jbigdaddylewis23]

Close