On May 29, 2013 2:47 PM, "Ingo Karkat" <[email protected]> wrote:
>
> 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.
For python-only plugins no API for plugin management is needed: there
already is pip. Something for initializing plugins installed by pip would
be fine though: currently used convention for the only python-only plugin I
know is
python from powerline.vim import setup; setup(); del setup
which would be better joined with pip interaction and hidden in
set pipinstall
call pyload('powerline.vim', 'git+git://github.com/Lokaltog/powerline')
(second argument is passed to pip install in case import fails; is
optional; absent argument counts as "powerline"; zero disables autoinstall;
set nopipinstall (default) disables this behavior for all calls) alongside
with a trick that avoids altering global scope (this is easy): Vundle and
VAM have already proved that users are not afraid of putting commands into
their vimrc.
API for mappings and menus is a separate issue, suggestions are welcome in
my RFC thread.
>
> -- 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.
>
>
--
--
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.
