Proposal: declarative, extensible cross plugin manager way to describe plugins to install and activate

VAM vs NeoBundle (being successor of Vundle) - parallel installation - probability of failure etc.

Proposal: Common way to declare list of plugins to be

{name: "foo", "source":"vim.sf.net", "activated-onf-ft": ["C"]}
{name: "other", "source":"vim.sf.net", "flavour": ["c-development"]}
{name: "other", "source":"vim.sf.net", "flavour": ["c-development", "mailing"]}
....

Please pay attention to special keys: - flavour: It allows you to install only "c-development" plugins easily - activated-on-ft: this is as declarative as NeoBundle is at the moment

VAM currently does not declare plugins which get loaded lazily in a way VAM could use to prevent such plugins from being uninstalled (eg by VAMUninstallNotLoadedPlugins)

This could be fixed trivially. However there is still a second issue: parallel installation/updating which people might want.

I strongly feel that using VimL to get this task done will make everything less stable (like Shougo suggestst - so I vote for having a second implementation (eg python based) - to keep things as stable as possible and to minimize effort.

Such a second non VimL solution could also be used by foreign parties (gentoo, nix, ...) to install plugins based on vim-pi.

A simple json like format as show above would allow - both Vim and a python script to read which plugins to be installed/updated - would allow users to contribute which plugins they use (sry, this is important to find out where to spend resources on)

Still waiting for Shougo to document how big the benefit of parallel installation/execution really is.

Problems, complexity VimL solutios would create: - Vim was not written for async communication. Even resizing Vim causes unexpected interrupts (I would have to look at vimproc), but the main problems persist - Eg how to show messages if user is currently executing input() .. ? (message loops still get called to get user input, thus viml will be run then)

Even if VimL/Vim would be safe to use this way, this complexity would arise: - Need more commands to activate plugins, need callbacks (eg run this when plugin A, B and C got installed). You know this all from "future" like implementation from JS world (eg jquery and such) - Users start using Vim when its not ready (unexpected behaviour, will cause context switches and slow down user) - interrupts by "plugin xy is ready" messages

Parallel installation might cause a perception of being productive, but I don't think the user actually is.

We should have a reference implementation to download plugins in vim-pi so that all plugin managers can take advantage of vim-pi (without ending up in plugin manager war ..)

Comments (5)