Reply to message «Re: which plugin management system to use?», sent 20:36:11 24 March 2011, Thursday by Israel Chauca F.:
> 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
Is it supposed to do something like updating `world' file? You can combine VAM
and readfile/writefile:
" This is to be put to vimrc
let worldfile='~/.vam/world'
call vam#ActivateAddons(readfile(worldfile, 'b'))
command -nargs=1 -bar DisableAddons
\ let s:dlist=[<q-args>] |
\ call writefile(filter(readfile(worldfile, 'b'),
\ 'index(s:dlist, v:val)==-1'),
\ worldfile, "b") |
\ unlet s:dlist
(untested).
If when you said `disable' you meant unloading the plugin and reversing its
effects (mappings, commands, function, etc), then VAM could not help you here.
My plugins can be unloaded, but they were written with support of such
unloading
(actually, reloading) in mind.
Original message:
> 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
signature.asc
Description: This is a digitally signed message part.
