Refactor duplicate logic in installers

[junegunn]

This commit extracts duplicate logic out of three installers; vimscript, ruby, and python.

Summary:

• The steps after git fetch or git clone is now done in Vimscript.

Pros.

• Better maintainability
• Easier to add/extend the features
• Fixes a bug when 'commit' option is used, submodules are updated
  before the designated commit is checked out

Cons.

• The whole process takes slightly longer due to lost parallelism after pull
• Especially, submodule updates are not parallelized
  • However, this shouldn't matter much in practice as there are very
    few plugins that heavily rely on submodules
• No streaming output (or timeout) during submodule update

[starcraftman]

My thoughts:

• Feels like a step back resorting to a for loop that blocks on commands after executing in a parallel context.
• I like how it consolidates things logically in update_finish, at least from the code pov.
• The usage of line 4 to display messages of different actions for different plugins is jarring since user currently expects almost all messages (except post update hooks) on the plugin's log line. It goes bit too quickly to really read.
• Could we make a function like s:update_finish_plugin(plugin_name) and call it from the threads?
• The installer seems frozen when processing YCM's extensive submodule dependencies, this is quite noticeable even with warning. Especially without any message on current submodule.
• Ctrl-C will seem odd as after exiting the installer, this for loop and other commands continue executing. At least one or more (if say you stuck in submodule command) will be required.

Seems like a mixed bag to me. I like the reduced duplication moved to update_finish, but don't like the actual user experience effects.

[junegunn]

True that this benefits developers not users. Nevertheless I think this is something we have to do in order to move vim-plug forward. One option is to create a devel branch with this and to do experimental stuff on it. Here are my thoughts on the points you made.

blocks on commands after executing in a parallel context.

Yes, we lose some parallelism here. But the commands are short-lived except for submodule updates. I have 58 plugins in my arsenal and this change makes :PlugUpdate99 take 1 second longer, which is of course not desirable, but still not unacceptable. It is unlikely that a user will have more than one plugin that heavily rely on submodules (I might be wrong though, and we all know that I'm referring to YCM), so the lost parallelism shouldn't affect the entire processing time by much, because even with parallelism, we'll almost always have to wait for it to finish.

The usage of line 4 to display messages of different actions for different plugins is jarring since user currently expects almost all messages (except post update hooks) on the plugin's log line. It goes bit too quickly to really read.

The experience is subjective and I can't argue with how you feel. But for me it's okay since the plugin's log line is eventually updated, and the fast changing line gives the feeling (or illusion?) that vim-plug is moving fast :)

Could we make a function like s:update_finish_plugin(plugin_name) and call it from the threads?

This would be ideal, but I don't think Vimscript is thread-safe. I haven't tried it for a while, so maybe things have changed, but when I first started working on vim-plug, I experienced inexplicable crashes, and had to use locks around Vimscript block. I wonder if there's a guarantee that Vimscript is thread-safe. Ah, and even with this, since it's a vimscript, we can't have streaming output from submodule updates.

The installer seems frozen when processing YCM's extensive submodule dependencies, this is quite noticeable even with warning. Especially without any message on current submodule.

Yeah, this is pretty unfortunate. So I put a warning message, but that's not good enough. I had to extract submodule update because it should be done after branch/tag/commit is checked out. We're currently checking out commit after submodule update. This is a bug and it was my oversight.

Hmm, we can consider using :! instead of system call, like we do with do blocks. Neovim users will complain but that's another story.

this for loop and other commands continue executing

After interrupt, for loops only touches plugins that we had succeeded to pull at the point. We can make it stop immediately if it makes more sense.

[starcraftman]

This would be ideal, but I don't think Vimscript is thread-safe. I haven't tried it for a while, so maybe things have changed, but when I first started working on vim-plug, I experienced inexplicable crashes, and had to use locks around Vimscript block. I wonder if there's a guarantee that Vimscript is thread-safe. Ah, and even with this, since it's a vimscript, we can't have streaming output from submodule updates.

Ya, you are right. I was thinking with my ideal thoughts rather than the one that remembers what things really are. VimL remains not thread safe so if we did do it in VImL we'd have to mutex the call from python/ruby slowing down the parallelism anyway.

If only VimL had been thread safe all those years ago. I guess this is just one of those compromises, just makes me feel a bit "icky".

After interrupt, for loops only touches plugins that we had succeeded to pull at the point. We can make it stop immediately if it makes more sense.

Yes, aware it is just successful ones. I meant more user might find multiple interrupts required odd. I do think most would prefer we finish the processing of successful plugins, even though it does render the interrupt less immediate, especially if testing things.

[junegunn]

Updated the commit to use :! to update submodules so we can see the progress. It also seems to work well in Neovim:

and in gvim (macvim):

[junegunn]

Rebased and updated s:do to properly "regress" the progress bar on error.