On 7 March 2016, Bram Moolenaar <[email protected]> wrote:
>
> Lcd wrote:
>
[...]
> > The point is, the main problem packages are supposed to solve
> > is to be able to distribute groups of plugins as packages. So one
> > could have:
> >
> > pack/mypack1/opt/plugin1
> > pack/mypack1/opt/library1
> > pack/mypack1/opt/library2
> >
> > pack/mypack2/opt/plugin2
> > pack/mypack2/opt/library3
> >
> > and one would be able to enable / disable mypack1 and mypack2
> > independently to one another, with
> >
> > packadd mypack1
> > packadd mypack2
> >
> > It seems to me this would make more sense than the current
> > scheme:
> >
> > packadd plugin1
> > packadd library1
> > packadd library2
> >
> > packadd plugin2
> > packadd library3
> >
> > --- simply because there's no point in having enabled just plugin1
> > and library3.
>
> The mypack1 plugin would contain the packadd commands to load the
> libraries it uses. And that can change over time. The user should
> only do "packadd plugin1" and "packadd plugin2", the rest is loaded by
> the plugins.
Hmm, packadd can be nested. This is an interesting point, I don't
think any of the popular plugin managers have an equivalent feature.
/lcd
--
--
You received this message from the "vim_dev" 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
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
