On 09-Feb-16, Bram Moolenaar wrote:
>
> 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.
Because I may prefer using plugin A, but when plugin A does not work, I
may want to use plugin B instead.
A plugin cannot know my preferences about this.
Also, when A and B are alternatives that cannot both be loaded (one
excludes the other), as in Gary's 'netrw' example, the user may need to
choose between A and B, depending on Vim's version or features.
But I agree that plugins generally should refuse to load when they
cannot work with the version of Vim that tries to load them.
Still, an experienced user or a plugin packager should be able to make
better decisions than the plugin writer, because getting all the
conditions right under which a plugin works can be a challenge, and some
conditions may only become apparent in some specific setup.
And when more conditions are figured out by users or plugin
packagers, tried and tested, these could be forwarded to the plugin
author. (Unless they are very specific to some distribution or
setup.)
It may be possible to specify plugin dependencies to Vim, so Vim can try
to load plugins in the order dictated by a dependency graph, so that if
plugin A does not load or is disabled, it attempts to load plugin B.
And some plugin C is only loaded when plugin B has been loaded.
To make this work, Vim also needs a reliable way to find out if a plugin
has loaded correctly.
Maybe like this: when during plugin loading the plugin does *not*
use 'finish', then Vim can consider the plugin loaded.
But some plugins load in stages, e.g. the taglist.vim plugin, so
they use 'finish' even when loading successfully...
> 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.
If we find a way to specify plugin disable/enable information and plugin
dependencies to Vim, and a way to check if a plugin loaded successfully,
then this and the issues above could all be covered.
> > 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.
Cleaning up &runtimepath is one thing I like about this idea. The other
thing is that each plugin lives in its own little directory subtree, so
it is easy to install, remove and update.
Also, in many cases we can try to load a plugin to see if the plugin can
work with the current Vim.
Now if we also can specify plugin disable/enable information and plugin
dependencies (between each other and on Vim features) to Vim, and find
out when a plugin loaded successfully, and if all this can be done in a
simple and reliable way, this could be an alternative to &runtimepath.
--
Olaf Dabrunz (oda <at> fctrace.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.
