Reply to message «Re: Way to skip systemwide vimrc?», 
sent 19:16:49 13 May 2011, Friday
by Ben Schmidt:

> Mmm. I suspect a lot of plugins do this, and I think it's actually poor
> Vimscript.
Why?

> Scripts should only do this, following the example of things like
> matchit and other bundled plugins, and indeed many of Vim's features
> through its runtime files; they should set a global, e.g.
> loaded_matchit, and not load if that is set.
What for? If I want, for example, disable format.vim plugin, I will put 
g:formatOptions={'DoNotLoad':1} into vimrc. But plugin in question loads in two 
turns: first, commands and functions are registered (for commands: pluginloader 
creates command that will load script and then do something, for functions: 
FuncUndefined event is created). Second, if some command or function is called, 
then plugin is sourced for the second time. If I will only use global variable 
instead of script-local, I will enable user to interrupt the second load which 
I 
don't want.

> That allows the plugin to
> be disabled by setting that global ahead of time, but also allows for it
> to be enabled later by unsetting the global and sourcing the plugin
With separate option for not loading plugin it works as well.

> (and
> if it is really well written, it should also provide a way to turn
> itself off by means of a command, and/or be able to be loaded gracefully
> more than once).
Almost all my plugins (deprecated): ``LoadCommand unload {pluginName}'' will 
unload plugin (turn it off if you wish), ``runtime! plugin/{pluginName}.vim'' 
will enable it again (but plugin dependencies will still be unloaded).
To reload plugin after update: ``LoadCommand reload {pluginName}''.
This functionality is provided by vimpluginloader framework, not by plugin 
itself.

With new frawor: ``call FraworUnload('plugin/{pluginName}')'' for unloading, 
``call FraworLoad('plugin/{pluginName}')'' for loading,
``call frawor#Reload('plugin/{pluginName}')'' for reloading. For now you can 
use 
this only for frawor itself.

In all cases reloading a plugin (for update) cannot be done by just resourcing 
it: pluginloader (and then frawor) were desinged to work around a case when I 
removed some variable/function/whatever and want to be sure that it cannot be 
used anymore (simplest way: make reload remove it). I see no advantages in 
using 
`default' way with a single global variable, but I see a disadvantage: global 
scope is polluted by lots of really script-local variables. Script-local 
protector+global deny-loading option is much cleaner.

Though I should now think about the case `user forbad to load a plugin that is 
a 
dependency of another plugin' (be calm, global variable won't solve this issue).

Second issue is that you should name this global DoNotLoad variables somehow, 
so 
I guess I will replace `separate DoNotLoad options for separate plugins' with 
`one DoNotLoad option holding a list of plugin names for all plugins that use 
Frawor' in order not to do the job that can be done by computer.

Original message:
> >> That's a nice piece of Vimscript. Probably overkill for this situation,
> >> at least if only run at startup before there are likely to be any local
> >> variables, but it's still pretty cool.
> >> 
> >> Now if we just had a way to do script vars....
> > 
> > Without ability to purge script variables this code should not be used
> > after plugins are sourced: for example, you will render all my plugins
> > useless because they use script variables as guards
> 
> Mmm. I suspect a lot of plugins do this, and I think it's actually poor
> Vimscript.
> 
> > (and also check for particular global variables to provide a way for
> > user to disable them,
> 
> Scripts should only do this, following the example of things like
> matchit and other bundled plugins, and indeed many of Vim's features
> through its runtime files; they should set a global, e.g.
> loaded_matchit, and not load if that is set. That allows the plugin to
> be disabled by setting that global ahead of time, but also allows for it
> to be enabled later by unsetting the global and sourcing the plugin (and
> if it is really well written, it should also provide a way to turn
> itself off by means of a command, and/or be able to be loaded gracefully
> more than once).
> 
> Ben.

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to