Dear Ron Aaron,
VAM can already do almost everything you propose:
- it knows which plugins have been loaded
- it can "blacklist" plugins (currently only used when bisecting, but
the feature is there)
- the user can 'opt-in' easily.
- user can load plugins at runtime after Vim was started up
You probaly already know this, so let me comment on your proposal which
mainly tries
- to outsurce if exists('g:is_loaded') | finish | endif
- provide a common way for adding menus - ignoring that similar problems
for mappings and commands might exsist.
Summary: I'd vote for distribtung such PlugCanLoad (with some changes)
with Vim - however I stopped using it (see below).
I'm not sure that the other features are important enough.
What is not implemented:
- min version constraint
- plugin menu handling
But let'l discuss details:
> PlugCanLoad
Which constraints to exist in practise making people load /
not load a plugin?
1) vim version (you have this)
you don't have these:
2) vim patch level
3) any of the :h 'feature-list' features (client-server, python, ruby, .. )
Now that python gets improved people will eventually start writing
"python-only" plugins. Of course providing a api just calling
PlugCanLoad etc is doable.
Thus it does make sense to extend your command:
PlugCanLoad name version patchlevel 999 requires python,ruby,client-server
if there is an arg 'patchlevel' expect a patchlevel number
if there is an arg 'requires', check using has() function
Additionally: if you cannot load plugin because constraint didn't
match use echom method to tell the user. If he is missing something
he'll see using :messages. Its unobstrusive.
I wrote something similar initially, because
if exists('g:is_loaded')
finish
endif
let g:is_loaded = 1
is just verbose. I returned a string and executed it using "exec". I
hate copy paste as you do. So I undestand why you want to "outsource"
this.
However I stopped using those guards. Why do they exist?
If you create a clean interface:
plugin/user-setup-and-au-commands.vim
autoload/the-implementation.vim
reloading is that cheap that I stopped caring. If you do not use
such a guard, you can use the 'reload' plugins to reload a plugin file
automatically which is nice for developping.
Details I think are good practises can be found here:
http://vim-wiki.mawercer.de/wiki/topic/designing-a-vim-plugin.html
Note: if you care about old vim installationss, those people have to
care about getting your version of "plugin-management", otherwise
they'll get "unkown command" errors.
> so the manager will not let the plugin load. This can be used either
> to inhibit the loading initially, or to reset it so one can reload a
> plugin.
Why not call it "DontLoadPlugin foo" then?
Why not be more human friendly, descriptive ? :)
What about accepting a list?
DontLoadPlugins A B C D
> Inside the plugin, one can add to a global "Plugin" menu by doing:
> call PlugAddMenu('Excellent', 'Make this excellent', ":call
> DoSomethingExcellent()<cr>")
> The advantage of such a scheme is that all plugins can put menus in a
> uniform location without conflicting (well, the topic names need to be
> unique...)
Why not do the same for mappings? Plugins can confilct, too.
I don't think you can solve this other than people maintaining plugins
choosing sane defaults for mappings, commands and menu items.
So if you propose a standard, we could start by writing the 'perfect
sample plugin' people can clone.
Marc Weber
--
--
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/groups/opt_out.
