Reply to message «Re: which plugin management system to use?», sent 08:49:13 24 March 2011, Thursday by Marc Weber:
> We could also extend VAM to allow directory prefixes: > > call ActivateAddons(["dir-a/snipmate","dir-b/python-support-plugin"]) > > However there must be strong arguments making me vote for such a > feature.. If you do this VAM will be one step closer to the state where I will be forced to do complete rewrite: just like I do now with vimpluginloader as I realized that 1. to add a new feature I want I need to modify code in too many places 2. if I had chosen better architecture, I could have written most of features that are already inside vimpluginloader as the separate plugins, where everything related to the feature is stuck in one place. Now VAM can make some benefit of being an addon that is extended by plugins, but this benefit is small in a short term. In a long term, things may appear reversed though. > So the only idea which comes to my mind is running kind of update > command by cron-job each week which is the only thing VAM can't do > nicely without scripting vim using -c --cmd. I think `-c' will be nice enough if I redefine `s:confirm' so that under some circumstances (like presence of particular global variable) it will take reply from a global variable instead of user. It is partly done by `auto_install' option, but not for #Update if plugin list is not given. > Well - then restart it and be happy :) > > Looks like there is a potential user who finds VAM's RTP handling is too > bloated. > We tried so hard keeping code to a minimum :) Maybe he is talking about reviewing the code before sourcing: I believe this is why you added :InstallAddons command. Original message: > Excerpts from Israel Chauca F.'s message of Wed Mar 23 19:56:42 +0100 2011: > > call Use(dir1, dir2) > > I guess that adding a vam#Use() function should take no more > than 10sec. > > We could also extend VAM to allow directory prefixes: > > call ActivateAddons(["dir-a/snipmate","dir-b/python-support-plugin"]) > > However there must be strong arguments making me vote for such a > feature.. > > > True, but there is no reason why the rtp manager couldn't handle that > > task. > > Would you mind talking about the two different versions you're using? > I'm curious about this particular use case. > > > - A command line interface > > Which commands would you run how often - and why? > It looks to me that you want a command line interface because you want > to install plugins before Vim starts up - because your rtp management > can't handle adding plugins after Vim started up. > > So the only idea which comes to my mind is running kind of update > command by cron-job each week which is the only thing VAM can't do > nicely without scripting vim using -c --cmd. > > > > How do you select the one or the other set of plugins when you need > > > them? > > > > We haven't implemented this yet, all 'bundle' dirs are used. but I was > > thinking that giving a partial or absolute path would be enough to > > select one of them. Since we have a list command that shows all bundle > > dirs and plugins, we could put numbers to every line of the output and > > work like :ls and :buffer. > > Well - because VAM stores plugins beneath it you can even use this > scheme: > > if $VAM_SET == 'python' > set rtp=~/vam-python-ide > " plugin list 1 > call vam#Activate([...]) > else > set rtp=~/vam-default-setup > " plugin list 1 > call vam#Activate([...]) > endif > > Then you have two different installations. You can swtich set of > plugins by one of: > > 1: VAM_SET=python vim > 2: vim > > If you combine this with getting the list of names from directory you > almost have what you're looking for ? > > > > command ActivateAdditionalPluginsA ActivateAddons additional-A > > > command ActivateAdditionalPluginsB ActivateAddons additional-B > > > There are rare cases where order of activation matters. > > > > I'm not sure about your example, would you have a command for every set > > of plugins? When it's implemented the way to do this should be > > > > :Plugin bundle disable bundleA > > > > or something similar. > > Can you tell me how you want to describe which plugins belong to a > bundle? How do you configure it? > > Should it look like this way: > > .bundleX are files: > > .bundle1 : plugin1,plugin2,plugin3 > .bundle2: plugin3,plugin1,plugin5 > > Or do you even want Vim to write those files for you: > :CreateBundle bundle1 plugin1,plugin2,plugin3 > > Do you then want to provide commands: > :AddPluginToBundle bundle1 bundle6 > :ClearBundle > :DelBundle > :DropPluginFromBundle > : > : ... ? > > (This looks like bloat to me - but my taste may be different) > > Don't forget: We're talking about manipulating a list of plugin names > only. If the standard doesn't fit your needs then you can just write > your own solution manipulating this list of names. > > > Does activation implies VAM sourcing the files? If so, I don't like > > it, I really want to just modify rtp and let Vim do its job. I don't > > care that much if I have to restart Vim after installing/removing > > plugins. > > Well - then restart it and be happy :) > > Looks like there is a potential user who finds VAM's RTP handling is too > bloated. > We tried so hard keeping code to a minimum :) > > VAM can also set a runtimepath explicitely for plugins. Some > distributions (eg ensime) provide plugin-dir/vim/autoload. > > So you have to handle this all manually. In VAM you set runtime to a > relative path "vim/" once for all users and be done. > > So I expect you to keep extending your code rather than "vimming". > > Anyway I'm glad that parts of VAM did help you. > > Marc Weber
signature.asc
Description: This is a digitally signed message part.
