Hello,
Meikel Brandmeyer <[EMAIL PROTECTED]> wrote:
> some days ago, there was a short discussion on #vim, that one cannot
> easily prevent plugins from loading. A distribution could install some
> scripts/plugins in the system-wide vimfiles directory, but the user
> could not defend against such a "pollution". Each plugin uses a
> different guard, so it's tedious to find out which one keeps a script
> from loading.
Disclaimer: I don't feel directly concerned as my vim distribution are the
sources from svn (for solaris), or the cream-lite one (i.e., without cream
itself).
But, I see very well the problem at hand you want to solve. And I must admit,
that at times it would be much simpler than the "mv
{,inhibited/}plugin/fooplugin.vim" that I use. (bash syntax)
> I thought a bit about this problem and came up with the following
> solution: Gatekeeper. Gatekeeper keeps track of which plugins the user
> wants to load, which plugins the users dislikes and which he doesn't
> care about. So it is easy to disable specific plugins.
How does this solve the problem of the distribution of old plugins that don't
use gatekeeper? I'm not sure the vim maintainers for the many distributions, are
ready to patch by hand hundred of files, and keep them synchronized with any
correction made by the plugin maintainers (in case the later ones don't make
their plugins gatekeeper-compliant)
> On the other hand gatekeeper also provides an opt-in way of handling
> plugins, where no plugin is loaded unless the user explicitly allows the
> plugin to be loaded.
How can it prevents "runtime! plugin/*.vim"?
> From the script's perspective using gatekeeper is quite simple. It is a
> single function call, which is used in the plugin guard header, which
> prevents the script from being sourced multiple times. In fact,
> gatekeeper even simplifies this header, since the normally used guard
> variable is hidden away.
Which doesn't help us, script maintainers to reload a plugin.
Well, to be honest, it not really a problem as we can always comment the finish
line (as long as we don't forget to restore it later). However, now my plugins
checks a exists("g:force_reload_{plugin}") in the first test.
BTW, I've seen an anti-reinclusion guard in your autoload plugin. In my
experience, it serves no purpose as autoload plugins already hide away all the
dependencies checks we had to do by hand in interdependent plain plugins.
> Further versions could even consider certain versions of a script, or
> inter-plugin dependencies.
This should disappear at terms thanks to autoload plugins. (Well, I hope so)
> Positive things I see:
> * Gatekeeper is easy to use.
Indeed, it seems so. It could also be interesting to use gatekeeper as an
interactive plugin that let the end user select what he wants.
> * In fact it may even simplify the header guard.
I don't really agree on this one for the previous reasons I gave. Moreover, all
my headers are generated with a template-files expander that provides the
adequate anti-reinclusion guards for plugins (1 global guard), ftplugins (1
global + 1 local guards), local_vimrcs (1local + 1 global), or whatever other
vim script (0 guard).
What is hidden in this last sentence, is that gatekeeper does not help with
ftplugins. When the ftplugin is just one file, blocking it is easy. When it is a
suite made of many plugins, and ftplugins, blocking it with one assignment in
the .vimrc becomes a much more complex task, and the call cannot even be used as
an anti-reinclusion guard (see for instance LaTeX-Suite (or my C&C++ suite,
which I don't distributed in any distribution before a very long time)).
> * It provides full control over plugins.
"over _compliant_ plugins", and only plugins. Unless vim is more deeply patched.
> * It may be used to check for dependencies. (for the future)
Except it becomes a new dependency itself. If it ever becomes an official part
of vim, this means, that we will have to maintain two branches of our plugins
for (a little less than) a couple of years, the time everybody migrates towards
a recent enough version of vim.
> Negative things:
> * It must be supported by the plugin. (For a distribution this can be
> easily accomplished with a simple patch.)
>
> So I'd like to drop this on the list with a request for comments. Any
> comments on the idea are appreciated.
In conclusion, that's a very interesting idea. But I'm afraid this is not as
simple as it looks like.
--
Luc Hermitte
http://lh-vim.googlecode.com/
http://hermitte.free.fr/vim/
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
