Olaf Dabrunz wrote:
> On 09-Feb-16, Bram Moolenaar wrote:
> >
> > I had another idea. Currently when installing a plugin or support for
> > a language, the files are scattered over different directories under
> > $VIMRUNTIME. That makes it hard to update them.
> >
> > How about this: use $VIMRUNTIME/bundles. Below that will be the
> > directories that are usually directly under $VIMRUNTIME. For example,
> > netrw would be installed in the directories:
> > $VIMRUNTIME/bundles/netrw/plugin
> > $VIMRUNTIME/bundles/netrw/autoload
> > $VIMRUNTIME/bundles/netrw/syntax
> > It doesn't need an "indent" directory.
>
> I like the idea.
>
> But it should be easily possible to enable or disable plugins.
>
> E.g., I enable some of my Vundle plugins conditionally depending on the
> features in the vim version that I start:
>
> if has('iconv')
> Plugin 'mbbill/fencview'
> endif
>
> if has("python") || has("python3")
> Plugin 'SirVer/ultisnips'
> else
> Plugin 'MarcWeber/vim-addon-mw-utils'
> Plugin 'tomtom/tlib_vim'
> Plugin 'garbas/vim-snipmate'
> endif
>
> This is esp. relevant on Fedora, where "vi" is a tiny build of vim (I
> believe), and "vim" is a huge build of vim (I believe).
Why does every user need to take care of this? The plugin should check
for features and skip if it is missing something.
I would also prefer Plugins run by default, and have some way to disable
them when you don't want them. Most plugins should just be used, only
in some cases would you want to skip one.
> Also, the compatibility issues need to be addressed.
>
> Some of them may go away simply by using a different subdirectory name,
> such as "plugpacks" instead of "bundles". Old plugins and plugin
> managers can use the old and known subdirectories, together with the
> known &runtimepath methods of including them.
>
> It should be possible to find out if a plugin is compatible with the new
> "plugpacks" subdirectory scheme. This is the difficult part, because
> how do we do this without requiring a flag in the plugin, which must be
> present in all future versions as well?
>
> It may not be so bad to have a flag, it can just become part of the
> boilerplate template for a plugin.
>
> But a standard boilerplate template for a vim plugin does not exist yet,
> to my knowledge. Google tried to make one, but AFAIK it did not catch
> on.
I'm afraid that if we want to be backwards compatible with plugins that
depend on the runtime file layout we might be stuck in a sub-optimal
situation. And every plugin manager finds its own way, making it even
worse in the long run.
I think it's not too bad to support the proposed directory layout. In
most cases everything will just keep working. In case some plugin needs
to find other plugins, and can only find other plugins from
'runtimepath', then we can make that plugin add itself to 'runtimepath'.
Worst case all of them, using globpath(&runtimepath, 'bundles/*').
I do think we need to get rid of adding lots of directories to
'runtimepath'. It's supposed to be an option set by the user. The only
reason plugin managers use it is because there is no alternative.
--
panic("Foooooooood fight!");
-- In the kernel source aha1542.c, after detecting a bad segment list
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
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/d/optout.
