What is the use case for a Vim script manager? I've never understood what this offers over including a full .vim in your version-controlled dotfiles. With a script manager, you have to worry about repositories disappearing, Github being down, and also breaking changes (unless you want to track a SHA on each one).
With a simple .vim, your Vim configuration is a living, breathing thing, and you can easily modify any script you're using the moment you find a bug in it that interrupts your work: You own your vimfiles. When you manually upgrade a script, it's trivial to roll back to the last version that worked. I guess dotfiles are the last place I want to introduce needless indirection: They should represent my work environment at a point in time, precisely.
I can only see two benefits: The ability to try out new plugins quickly, and the ability to upgrade all of your plugins at once quickly. Are these worth sacrificing control over your editor config? This has puzzled me since the day tpope released Pathogen to much fanfare.
I did the whole single .vim in git before switching to a script manager and I consider it a huge improvement.
- It's easier to install a new plugin, no more unzipping and copying files manually.
- The files from different plugins don't get mixed up together anymore
- which mean is also easier to remove one
- and also no file name conflict.
- If I have a bug somewhere it's easier to disable each plugins temporarily to find which one cause it.
- Easier to update a plugin
- My modification to my .vim don't get mixed up with the upstream updates from the plugins. If I want to modify a plugin I just fork it (and try to have my modification merged)
- In fact I don't really have a .vim anymore, I put everything in my .vimrc which is a nicer to read centralized location. If some part become too big I just refactor it in a separate module that I install with the manager.
> Are these worth sacrificing control over your editor config?
You're not sacrificing any control. I'll speak only of the ones I know: vundle, neobundle, and vim-plug are using very basic Vim mechanisms to save you the hassle. Appending to &runtimepath is the Vim equivalent of modifying your shell $PATH.
And deferred loading, if you choose to use it (I don't), actually gives you more control over plugin behavior.
> You own your vimfiles
This is emacs mentality. I don't want to own (read: maintain) the plugins I use. If I find a bug, I send a PR upstream so others can benefit. If the bug is unforgivable I uninstall the plugin. (You can also pin to a specific SHA).
I think that plugin managers (further complexity in editor configuration) are Emacs mentality. See, ELPA. The approach I'm describing is how people maintained their vimfiles before plugin managers became popular.
New Vim users are told to use a plugin manager now if they want to install other users' scripts, and I believe that is a flawed approach to configuring a lightweight editor like Vim.
You couldn't be more wrong. Maybe if you have 4 plugins this is a workable strategy. What if you have 20 or 50. How on earth do you update any of them cleanly?
It's because of comments like this that I've reserved my opinion about Vim script managers, of all things, for many years. There's no "right" or "wrong," I favor a tightly integrated editor setup where I own my plugins. Further, I don't believe that reaching for a plugin every time you have a problem to solve is the best or only way to extend your editor. My .vim probably has 10-30 third-party script collections, but "upgrade all vim scripts" isn't something I've ever wished to do at the same time. I prefer to upgrade plugins that I know to be active projects after reviewing the changelog, and I do this about once a year.
Is it so hard to relate to the desire simplicity and control in editor config? It's one place where I want to keep the cognitive overhead as low as possible: No forking git repositories to fix a bug in somebody's indent script that's not been maintained since 2007.
You can always clone/fork the repositories of the plugins you're using. Having moved from a big repo for my .vim + .vimrc to Vundle, I appreciate the possibility of quickly adding and removing packages.
Vim scripts are barely even packages! Package managers for operating systems and build dependencies? Certainly. Does everything need package management? Only a small subset of all vim scripts have any dependencies. Tim Pope was the first person I remember introducing a script dependency (tlib) and I thought it was a ridiculous decoration at the time. A good vim plugin should be self-contained, in my opinion.
I recognize that this is really a misgiving I have with the direction Vim is going, towards complexity (plugin managers, multithreaded implementations). NeoVim looks like the final push that makes Vim configuration and operation truly byzantine. Then everybody gets to pick between Emacs and VEmacs.
You have confused the inability (and frankly unwillingness) in the Vim community to add new features as the virtue of simplicity, while in fact, its the tail wagging the dog. Vim's source is an abomination of global variables, copy paste, and decades of hill climbing. Vim still maintains support for e.g. Amiga and probably a dozen different language bindings. It is Vim's byzantine implementation and not some philosophical purity that guides its development (or really lack thereof). There is nothing simple about it. This mess is NeoVim's raison d'etre.
> towards complexity (plugin managers, multithreaded implementations). NeoVim looks like the final push that makes Vim configuration and operation truly byzantine
There's nothing simple about the Vim source, but Neovim has cut it in half, and modularized it. The Neovim strategy is similar in spirit to a microkernel, or shell tools: let the Vim core operate on inputs, and let external tools (GUIs, plugins) operate on the outputs. Like `find . | grep -v foo | sort` involves three self-contained, well-defined tools.
Because blocking the UI thread for any kind of I/O network, process, file, whatever is such a great thing. Or even just syntax highlighting, which actually prevents you from being able to move your cursor in vim sometimes.
Vim's source code is an abomination, and Neovim is making it unquestionably better.
Sorry, I can't even feign concern about the state of Vim's source code. I'm a Vim user and plugin developer, not a Vim developer.
A single-threaded UI means I can easily tell what Vim is doing at any time. It means the editor never feels clunky because indexing or some other background activity is hogging resources. It also means I never get a "process is running" prompt like in IntelliJ or Emacs when I want to exit.
> It also means I never get a "process is running" prompt like in IntelliJ or Emacs when I want to exit.
No, instead you find that you can't :q - or type anything for that matter - because everything's frozen while vim is realising that the network drive is down, or you're waiting for the syntax highlighting to finish.
And then you hit control-C and resume editing. None of this is as dramatic as you describe, and syntax-highlight freezes aren't as common now with the improved highlighting algorithm in 7.4.
With a simple .vim, your Vim configuration is a living, breathing thing, and you can easily modify any script you're using the moment you find a bug in it that interrupts your work: You own your vimfiles. When you manually upgrade a script, it's trivial to roll back to the last version that worked. I guess dotfiles are the last place I want to introduce needless indirection: They should represent my work environment at a point in time, precisely.
I can only see two benefits: The ability to try out new plugins quickly, and the ability to upgrade all of your plugins at once quickly. Are these worth sacrificing control over your editor config? This has puzzled me since the day tpope released Pathogen to much fanfare.