On 29-May-2013 09:20 +0200, Gary Johnson wrote:
> On 2013-05-29, Marc Weber wrote:
>
>> 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.
>
> The nice thing about those guards is that they are generally
> consistently used by most plugins, so a consistent mechanism is
> available for the user who is not using any of the plugin managers
> and wishes to either:
>
> 1) not load the plugin at all; or
> 2) put a modified version of the plugin earlier in 'rtp'.
>
> I think that this guard or its functional equivalent (e.g., a
> built-in command similar to CompilerSet) should remain as part of
> the standard plugin template.
>
> They may be verbose, but they're also idiomatic so you don't really
> have to read all four lines, just notice the pattern.
I agree; in the near to mid time frame, any sort of plugin manager will
be employed only by a minority of plugins. (To get a feeling for how
adoption of such interfaces proceeds, check how many plugins support the
GetLatestVimScripts annotation.) There are many plugins on vim.org that
aren't maintained any more, but still work just fine. And vim.org is not
the only repository (some scripts are only on sites like GitHub), so any
push to adoption will be hard. But inconsistent approaches seem worse
like the situation today.
And all that to avoid a few lines of boilerplate code?! I like the fact
that Vim doesn't prescribe a way of plugin management; though there are
now many good and widespread offerings (Pathogen, Vundle, VAM, etc.),
everyone is free to approach plugin management according to one's needs
and tastes.
However, if there will ever be a future movement to write Python-only
plugins, it would be great to learn from the past and introduce a better
API for plugin management, customizable mappings, menus, etc. right from
the beginning.
-- regards, ingo
--
--
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.
