(forw) Re: RFC: Gatekeeper - control which plugins are loaded
Stefano was having trouble sending to the group, so I am forwarding this for him. ...Marvin --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- ---BeginMessage--- [ resent: the first one was bounced back by google groups ] On Tue, Apr 22, 2008 at 06:36:08PM -0400, Marvin Renich wrote: Actually, I like Debian's approach (thanks Debian Vim Maintainers and especially Stefano Zacchiroli). Rather than force every plugin to use a Marvin, thanks both for the kudos and for forwarding to us this thread handle. I'm no longer following actively vim-dev these days, but I believe James Vega (the most active vim maintainers in Debian these days, and which deserves the kudos part on our responsiveness :)) does. My thought on this issue is as follows. I don't like reinventing wheels, and it is what possibly happened with Gatekeeper. I hope your message can help fixing this. We would be very happy Debian-side if our vim-addon-manager solution will spread outside Debian boundaries, it is by no means Debian-specific. Our policies for how to handle this are stored in the Debian Vim policy (http://pkg-vim.alioth.debian.org/vim-policy.html/) and can be read be whoever wants. Similarly, the vim-addons source code is available and free software. The implementation is probably suboptimal, but it is not a complicated piece of code, if there is interest in the wider vim-dev community we might even rewrite it from scratch! implementing perceived needs. Just let us know. Please remember to Cc [EMAIL PROTECTED] if you want to be sure that me, or someone else of the Debian vim maintainers, follows this thread. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature ---End Message---
Re: RFC: Gatekeeper - control which plugins are loaded
Hello,
Meikel Brandmeyer [EMAIL PROTECTED] wrote:
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.
I disagree. Obviously instead of modifying your plugin*s*, you would
just have to add the force flag to the central Guard function and *all*
your scripts support your flag immediately.
Well, if gatekeeper could also propose a way to force reloading (multiple times)
a plugin, that would be nice.
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).
This sound like a very special setup. It is hard (if not futile) to try
to cover all cases. What's of course possible, is to replace the central
Guard function. So there also some flexibility into this direction.
This is limited by the public API of course...
It is not that special at all. ftplugins are very close to plugins except that:
- they require a local guard
- sometimes they can need a global guard, for global definitions which can be
moved to autoload plugins now.
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 CC++ suite, which I don't
distributed in any distribution before a very long time)).
Hmm.. This is another point, which needs some thought. I didn't think
about multi-file scripts.
BTW, did you read David 2 cents about storing the version of a plugin in its
anti-reinclusion guard ?
This is a good practice that, I think, should indeed be generalized -- and I
have a lot of work to do on this one. This is something the Guard function from
Gatekeeper should take into account (may be with an optional parameter receiving
the current version of the script?) At terms, it could help to implement
dependency checks when a particular version of another script is required.
--
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
-~--~~~~--~~--~--~---
Re: RFC: Gatekeeper - control which plugins are loaded
On 23/04/08 00:20, Meikel Brandmeyer wrote: [...] I think of distribution not only of some batteries-included vim package, but also some system-installation. I worked as a system administrator during my study time and was responsible for 40 public dialog stations, where the students of our faculty could work. I consider it good practice to provide the users a comfortable system. If the first thing, they have to do, is to start installing software in their home directory, I did something wrong. So I'd also like to preinstall some of the more popular plugins. [...] The problem is: the user might have more than he wants. I like the way the matchit plugin is distributed: present but not active, so the only thing necessary to make it work (while still benefiting from future upgrades if any) is a $VIM/vimfiles/plugin/matchit.vim consisting of the one line runtime macros/matchit.vim For the help, it's harder to do it on Windows, but on Unix a softlink from $VIM/vimfiles/doc/matchit.txt pointing to ../../vim71/macros/matchit.txt does the trick. (For the plugin itself, the advantage of _not_ using a softlink is that (a) it works even on Windows and (b) if you have several Vim versions installed, each of them will use its own version of the plugin, thus sidetracking any compatibility issues.) Of course, it would be even easier with a Preferences popup menu including a Plug-ins tab with a set of checkboxes: _Plug-ins to be loaded at startup__ [x] matchit [ ] getscriptPlugin [x] gzip [x] matchparen [x] netrwPlugin [x] rrhelper [ ] spellfile [x] tarPlugin [x] tohtml [x] vimballPlugin [x] zipPlugin [x] syntaxcomplete [x] zzsplash including a couple I wrote myself; but, also of course, that kind of menu isn't the Vim way to do it (and BTW, IMHO a vimrc is more powerful than any closed set of Preferences). I believe it would be possible to implement it though (or something similar), with no change to the existing plugins, by means of 'noloadplugins' and as many lines (maybe :runtime lines at the end of the vimrc, or rather in a separate script called from the vimrc, to make it easier to change settings) as there are plugins to be loaded. You might want to save the initial status of lpl in order to avoid loading _any_ plugins when run with either -u NONE or --noplugin on the command-line. Best regards, Tony. -- Giving up on assembly language was the apple in our Garden of Eden: Languages whose use squanders machine cycles are sinful. The LISP machine now permits LISP programmers to abandon bra and fig-leaf. -- Epigrams in Programming, ACM SIGPLAN Sept. 1982 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: RFC: Gatekeeper - control which plugins are loaded
* Meikel Brandmeyer [EMAIL PROTECTED] [080421 17:46]: Hello Vim developers, 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. 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. [snip] 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. [snip] So I'd like to drop this on the list with a request for comments. Any comments on the idea are appreciated. Sincerely Meikel Actually, I like Debian's approach (thanks Debian Vim Maintainers and especially Stefano Zacchiroli). Rather than force every plugin to use a common interface to allow enabling/disabling individual plugins in a distribution, they built a vim-addon-manager package that allows the sysadmin to determine which plugins are enabled by default, and allows individual users to enable/disable each plugin separately, overriding the sysadmin's defaults. The global defaults are done by placing the scripts in a directory that is not in Vim's rtp, and then using symlinks to the system-wide enabled ones in a directory that is in rtp. Individual user preferences are likewise symlinks in the user's .vim/ directory structure. The only tricky part is disabling a default-enabled system-wide script. This is done by the Vim maintainers by manually determining for each script what to put in ~/.vim/plugin/000-vim-addons.vim to tell the script not to load (or make it think it is already loaded). More kudos to the Debian Vim Maintainers: Some people are really concerned about having the absolute latest patches to Vim and compile Vim themselves to that end. The Debian maintainers are very responsive, and while you cannot always get the latest patches in a binary Debian package, you can usually get very close. Currently, you can get official Debian packages with Vim 7.1-293, which is, indeed, the most up-to-date version. ...Marvin --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RFC: Gatekeeper - control which plugins are loaded
Hello Vim developers,
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.
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.
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.
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.
Further versions could even consider certain versions of a script, or
inter-plugin dependencies.
Positive things I see:
* Gatekeeper is easy to use.
* In fact it may even simplify the header guard.
* It provides full control over plugins.
* It may be used to check for dependencies. (for the future)
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.
Sincerely
Meikel
--
|\ _,,,---,,_
/,`.-'`'-. ;-;;,_
|,4- ) )-,_..;\ ( `'-'
'---(_/--' `-'\_) fL http://ec.kotka.de
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Vimball Archiver by Charles E. Campbell, Jr., Ph.D.
UseVimball
finish
autoload/gatekeeper.vim [[[1
112
# HEADER [ {{{ ]
Plugin: Gatekeeper
Version: 0.1
Author: Meikel Brandmeyer [EMAIL PROTECTED]
Created: Mon Apr 21 20:13:05 2008
Last Change: Mon Apr 21 2008
License:
Copyright (c) 2008 Meikel Brandmeyer, Frankfurt am Main
All rights reserved.
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the Software), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
Description:
Gatekeeper provides an infrastructure for scripts to handle dependencies
and loading of scripts. The user may easily disable certain scripts or
choose an opt-in mode, where each script must be explicitely enabled.
Missing or disabled dependencies give either an error or are simply enabled
if the corresponding switch is set by the user.
# [ }}} ]
# PROLOG [ {{{ ]
if exists(g:GatekeeperLoaded)
finish
endif
let g:GatekeeperLoaded = 1
let s:saved_cpo = cpo
set cpovim
# [ }}} ]
# VARIABLES [ {{{ ]
### VARIABLE gatekeeper#OptOut, gatekeeper#OptIn [ {{{ ]
Description:
Gatekeeper works in two modes: opt-in or opt-out.
opt-out is the traditional mode which is used by most plugins. In case the
user doesn't want the script to be loaded, he has to manually fiddle around
with one of the many ways to stop the script from being sourced.
opt-in is newly introduced by Gatekeeper and works the other way around. No
plugin is loaded unless specified by the user. In this way it is easy to
disable scripts.
if !exists(gatekeeper#OptOut)
let gatekeeper#OptOut = 1
endif
if !exists(gatekeeper#OptIn)
let gatekeeper#OptIn = 0
endif
### [ }}} ]
# [ }}} ]
# FUNCTIONS [ {{{ ]
### FUNCTION gatekeeper#Guard [ {{{ ]
Description:
This is the heart of the system. This function is used in the header guard,
which controls whether the script is sourced or not. Is a script disabled
this function indicates so back to the script which should 'finish'.
function
Re: RFC: Gatekeeper - control which plugins are loaded
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 CC++ 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
-~--~~~~--~~--~--~---
Re: RFC: Gatekeeper - control which plugins are loaded
On Tue, Apr 22, 2008 at 12:45:25AM +0200, [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). I too am blessed with a distribution (Gentoo) that doesn't install anything unless I explicitly ask for it. So I don't have this worry. But just as a thought -- couldn't the desperate user do something like vim --noplugin and then runtime! foo.vim for all the plugin's the user wants? GI -- One man's folly is another man's wife. pgpViqgXAy13o.pgp Description: PGP signature
