4 ms·

I don't understand your concern. It seems to me to be roughly the same amount of work whether you A) install vundle and maintain a list of plugins for it to fet

by hellcow 10y ago

I don't understand your concern. It seems to me to be roughly the same amount of work whether you A) install vundle and maintain a list of plugins for it to fetch or B) write a bash script that fetches each plugin. I actually prefer Vim 8's approach.

jmcdiesel 10y ago
Because i can install vundle with a single line in my setup script (already have a "provisioning" kinda script for each time i fire off a machine). I dont have to update that script for new plugins, its a single "Vundle user/repo" in the vundle.rc file. Vundle then installs it, and handles it. Could it be scripted, sure... but its much more readable in the vundle form (or other managers for vim), and its also in a more logical place... and its portable, even to a windows machine... its kinda a separation of concerns kinda thing...
- hellcow 10y ago
  > I dont have to update that script for new plugins, its a single "Vundle user/repo" in the vundle.rc file. You either add a single line to your vundle.rc file, or you add a single line to your bash script.
  - jmcdiesel 10y ago
    Still doesn't address separation of concerns... if you prefer a single monolithic script to do everything, thats cool, im not trying to change your mind, but for my tastes, i want my provisioning script to be as simple as possible, concerning only what it needs to, and let the apps configure themselves in a way that is obvious to anyone who uses my scripts (a few of my fellow devs use my stuff to bootstrap their setup)
jmcdiesel 10y ago
Also, disabling plugins is much easier... just comment the line... instead of delete the folder. That way, if im working through an issue that a plugin is causing, i can easily just toggle the plugin. Vim just loads whatever is in the folders, so i'd have to delete the folder, then readd it when i want it back... its less of a use case, but since i write vim plugins from time to time, its nice to be able to easily turn on/off my own plugins that may have bugs in them when i need to actually work...

by hellcow 10y ago

jmcdiesel 10y ago

Because i can install vundle with a single line in my setup script (already have a "provisioning" kinda script for each time i fire off a machine). I dont have to update that script for new plugins, its a single "Vundle user/repo" in the vundle.rc file. Vundle then installs it, and handles it. Could it be scripted, sure... but its much more readable in the vundle form (or other managers for vim), and its also in a more logical place... and its portable, even to a windows machine... its kinda a separation of concerns kinda thing...

hellcow 10y ago
> I dont have to update that script for new plugins, its a single "Vundle user/repo" in the vundle.rc file. You either add a single line to your vundle.rc file, or you add a single line to your bash script.
- jmcdiesel 10y ago
  Still doesn't address separation of concerns... if you prefer a single monolithic script to do everything, thats cool, im not trying to change your mind, but for my tastes, i want my provisioning script to be as simple as possible, concerning only what it needs to, and let the apps configure themselves in a way that is obvious to anyone who uses my scripts (a few of my fellow devs use my stuff to bootstrap their setup)

jmcdiesel 10y ago

Also, disabling plugins is much easier... just comment the line... instead of delete the folder. That way, if im working through an issue that a plugin is causing, i can easily just toggle the plugin. Vim just loads whatever is in the folders, so i'd have to delete the folder, then readd it when i want it back... its less of a use case, but since i write vim plugins from time to time, its nice to be able to easily turn on/off my own plugins that may have bugs in them when i need to actually work...