Re: RFE: Prevent maps from being overwritten with :map
Hello, > No worries, but I'd argue that they are not solutions since > they aren't currently working for me. I don't think the user > should be penalised if a plugin writer doesn't check for > existing mappings. The way it stands right now a user cannot > prevent a plugin writer from overwriting their maps. I'd > like to be able to define a map in my vimrc and not have it > be unexpectedly redefined in certain buffers, similar to the > may you might use use the `final' keyword in Java. Do you > foresee any problems in allowing users to do this? Maybe the community of active plugin developers should consider a kind of "Plugin Writer's Codex" -- how should a plugin behave. Such a codex should be small and simple in order to not shy away the casual plugin writer. But it should focus on a few important points and it should be actively advertised by the more "professional" authors. One possible point could be: - a common way to make mappings optional Maybe a second-level could be provided for those who want to dive deeper into plugin writing: - use - use Putting the burden on the user who has to take radical actions to get a plugin to behave well is really not an option for me. I think, with a high quality standard of the "professional" plugins, which are not only single shots to solve an immediate problem, the community would benefit in general. Just my 2ยข. Sincerely Meikel --~--~-~--~~~---~--~~ 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
Hello,
> Well, if gatekeeper could also propose a way to force reloading
> (multiple times) a plugin, that would be nice.
Please see the attached version, whether it does want you intend.
Basic Idea:
let gatekeeper#YourPluginDebug = 1
do
:source YourPlugin.vim
until you don't want anymore
unlet gatekeeper#YourPluginDebug
:source YourPlugin.vim does nothing anymore (the script is already
loaded)
> 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.
Ah, ok. Got it. Something like "b:foo_loaded" instead of "g:foo_loaded".
I was confused about the "local".
> BTW, did you read David "2 cents" about storing the version of a
> plugin in its anti-reinclusion guard ?
Quote from the named thread:
> I would like us (plugin authors) to develop a standard / best practice
> that everyone adheres to. This would make it useful for others as
> well.
Nothing more to add
> 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.
This could be done with the central Guard function without problems. But
for the handling probably one would need some support function.
Otherwise you get problems with the loading sequence. Maybe something
like Need(["Foo", "102"], "Bar", ["Frobnicate", "200"]).
There are a few things to take care of...
1. How to come from the plugin name to the filename?
Possibilities:
- both are identical
- the latter is all lowercase of the former
- ...
2. What format do we choose for version strings?
This is what David used: "vll".
There could be other formats like: "vvllpp".
In the end it doesn't really matter as long as it's consistent for a
given plugin. But it should be comparable like x < y. The guys from
rubygems have a quite nice versioning scheme, I think.
I'd like to use strings, BTW, because I often label my development
versions, before the first real release, with 0.. Then a
number doesn't really work well...
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
121
"# 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 o
Re: RFC: Gatekeeper - control which plugins are loaded
Hello, > Actually, I like Debian's approach (thanks Debian Vim Maintainers and [...] > make it think it is already loaded). Here are some comments about this way of doing things... * I read the word "symlink" several times. This most likely disqualifies this solution for Windows. * It most likely also doesn't work well with heterogeneous environments where Linux (Debian in this case) lives together with other systems like HPUX, where the file system layout is probably different. If the installation directory of vim is in a different place, then the symlinks won't work well. * One needs Ruby. (IIRC it is a Ruby script) The first two issues could be solved by copying the files. So my main concern with this solution is: it is probably not portable without serious drawbacks (copying is a serious drawback) and it needs an extra non-trivial prerequisite. My requirements for a solution to this problem are ... * It needs only vim. * It works where vim works. * It is easy to use (especially for the user). As was said before: the environment is like it is. There is the way vim works and there is the way the plugins are written. Given that you probably cannot easily change either one, the Debian way is a feasible solution. But I doubt, that it's universally applicable. I thank for all the rich feedback (also in the other mails of this thread). However there were no real no-go arguments, besides that the scripts have to be cooperative for the full support. With loadplugins option one can possibly also take care of not so cooperative plugins, although the possible control is restricted to the choice of loading or not loading. Supporting reloads is then probably not easily possible. So in general the idea seems to be feasible. Although there are certainly areas, where more investigations are due, eg. multi-file plugins. > More kudos to the Debian Vim Maintainers: They seem to do a good job. Chapeau. :) 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 -~--~~~~--~~--~--~---
Re: RFC: Gatekeeper - control which plugins are loaded
Hello,
> 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).
Ok. Maybe I should define a bit more, what I understand to be a
"distribution".
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.
> 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)
And this does not work, if the plugins where installed in the system
vimfiles hierarchy...
> 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
Obviously it does not. The scripts have to support gatekeeper, although
the loadplugins option, mentioned in another mail could be a rather
harsh helper here.
> How can it prevents "runtime! plugin/*.vim"?
Obviously it can not. It lives from cooperation. If the scripts use
gatekeeper, using runtime! or not makes no difference, since the scripts
obey to the user settings. If they don't, well, then they don't...
I also can't force a plugin to use . If the author chose not to
use it, I have to live with it or patch the plugin.
> 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.
> 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.
Good point. I saw this in other autoload plugins, and since it was the
"traditional way" I didn't really think about that.
> > 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)
Well the original question about dependencies came up as the following
scenario: The user disabled a script explicitly and then some other
script depends on it. What happens now? We could simply source the
dependencies ignoring the user's choice or we obey to his wish. Then we
need some feedback. With autoload the user just gets a "E117: Unknown
function: foo#Bar". Oeeh... and now? Maybe a "Script foo needs plugin
bar, but it is disabled" or "Script foo needs plugin bar, but it seems
to be missing from runtimepath" is maybe more helpful. Or even an
interactive question, which let's the user decide immediately, whether
to enable the dependency (if the script is installed, but disabled).
> 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.
One could check, which plugins are present, ask what the user wants to
do about them and save the state for future use. The user could invoke
the same procedure at any time to reconfigure his settings. Maybe it
could also recognise "new" plugins and give some feedback back to the
user. Of course only in case he chooses to receive such notifications.
Otherwise we stay out of his way.
This would need a bit more thought, how this could be worked out.
> 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...
> 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
> dis
Re: RFC: Gatekeeper - control which plugins are loaded
Hello, > vim --noplugin > :set noloadplugins Hmmm... I see. No one pointed me to that option up to now. Maybe one should make this more public? The only places I found a reference to it in the docs, is the option itself, the cli flags and the quickref. None of those I would start with for looking for such an option. Hmm.. Ok, maybe the quickref. Should use this more often. Maybe a reference at the plugin section makes also sense? 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 -~--~~~~--~~--~--~---
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 cpo&vim
"# [ }}} ]
"# 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("g
