On Mar 24, 2011, at 12:49 AM, Marc Weber wrote: > 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.
Something similar to having the system version of Vim in /usr/bin and the one I compiled on /usr/local/bin. Let's say I have two dirs, one is a shared one maintained by someone else (A), the other is the one I maintain (B). So, say I modify one of the plugins available on the dir A and I put on B, then I'd just disable the inside A and leave the other one working. But I don't think this is a big deal now, you guys have made me think and it doesn't sounds as important as it did. Right now I could just put my B dir before A, so its content takes precedence, just like with $PATH. That should be enough for most cases. >> - 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. It seems like I haven't been clear on this, whenever I wrote 'command line' I was referring to Vim's command line mode, not the terminal. I'm sorry for the confusion. So, I can disable a plugin with the following command from Vim: :Plugin disable pluginX >>> 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 ? Yes, that solution looks like the right thing. >>> 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? The plugins are listed under the name of the dir in the index file. > 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 Something like that, since I might not have write access to any of the dirs, the list with all dirs with their plugins is written to ~/.vim/bundled_plugins, one item per line. > 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) I have one command :Plugin with sub-commands (list, enable, disable, install...) with completion, something similar to git under zsh (don't really know how bash behaves there). > 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. Absolutely, I'm just sharing what I have/want :) >> 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 :) It shows, I'm really impressed and thankful for all the work you guys have put into making VAM what it is. > 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. And I'm thankful for that :) Israel -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
