Runtime files

[Bram Moolenaar]

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.

That way the directory can be put under version control or updated in
any other way easily. E.g. unpacking a zip archive that you get from
Charles's site. And it's also easy to get rid of: delete the directory
below bundles. No need to hunt down the files that you unpacked before.

This also makes it easier for plugin managers. No need to keep adding
more and more entries to 'runtimepath'.

A disadvantage is that startup will be a bit slower, since Vim has to
read more directories to find all the files. That's a small price to
pay. Especially if we only do this for some plugins, not all the
distributed ones. That implies that what's under $VIMRUNTIME/bundles is
found first.

--
Press any key to continue, press any other key to quit.

/// Bram Moolenaar -- Br...@Moolenaar.net -- 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 ///

[Nikolay Aleksandrovich Pavlov]

2016-02-09 13:03 GMT+03:00 Bram Moolenaar <Br...@moolenaar.net>:
>
> 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.
>
> That way the directory can be put under version control or updated in
> any other way easily. E.g. unpacking a zip archive that you get from
> Charles's site. And it's also easy to get rid of: delete the directory
> below bundles. No need to hunt down the files that you unpacked before.
>
> This also makes it easier for plugin managers. No need to keep adding
> more and more entries to 'runtimepath'.

This way VAM, Vundle and other non-pathogen users will have move
plugins out of ~/.vim/bundles. Neither of mentioned plugin managers
put *all* plugins found in ~/.vim/bundles to &runtimepath, they put
only those that were *requested by user*. This may also be used to
conditionally enable plugins. Or to install plugins for a trial and
use it only in one of many Vim instances during the trial.

So direct consequence of this is that bundles directory could no
longer be used by all (pathogen is not the one) plugin managers in a
way they use it currently.

>
> A disadvantage is that startup will be a bit slower, since Vim has to
> read more directories to find all the files. That's a small price to
> pay. Especially if we only do this for some plugins, not all the
> distributed ones. That implies that what's under $VIMRUNTIME/bundles is
> found first.
>
> --
> Press any key to continue, press any other key to quit.
>
> /// Bram Moolenaar -- Br...@Moolenaar.net -- 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 vim_dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Tony Mechelynck]

What about having packages that can be enabled/disabled in some other
directory? (let's say $VIMRUNTIME/packages) — which would not be
checked for plugins, ftplugins, syntax scripts, keymaps, colorschemes,
etc.; then in order to enable package foobar, add in
$VIMRUNTIME/bundles a symlink foobar -> ../packages/foobar. Or even
simply move packages into and out of bundles/ (and, in this example,
out of and into packages) to enable or disable them? (N.B. I'm not
sure about modern Windows, but on Linux the "move" operation moves
only the directory entry when the directories moved-to and moved-from
are in the same filesystem aka the same disk partition.)

Best regards,
Tony.

[Nikolay Aleksandrovich Pavlov]

I am reporting the current state. There are sure some workarounds (and
moving directories is not a good one), but still such change will
break.

Issues with moving directories:

1. Least significant is that plugins need to be searched in different
folders (symlinking: when removing a plugin one needs to care about).
2. And most significant: you cannot conditionally enable plugin from
the vimrc for a subset of Vim instances using the same algorythm, so
why bother writing two algorythms at all? I would just move managed
plugins from ~/.vim/bundles and ignore new functionality.

---

I also have forgot one major downside: e.g. my translit3 plugin looks
for its configuration by iterating over &runtimepath. There are many
other plugins (especially snippet ones) which do the same thing
(possibly using globpath(), but e.g. ultisnips iterates over
&runtimepath). So plugins which contain configuration for such plugins
(e.g. plugins with snippet collections) cannot be installed the new
way without being useless.

I also saw ultisnips using globpath(&runtimepath, 'syntax/*.vim') for
whatever reason. This code breaks.

---

Thus I would say that this idea is bad because it will break plugin
managers and it will break plugins using globpath(&runtimepath) or
similar techniques. It is also pointless: a big number of entries in
&runtimepath does not slow down Vim much compared to the IO from
iterating over that much directories (which will not change just
because you use another method for getting a list of directories to
iterate over), so the only benefit is that user can check that
something is contained in his &runtimepath easier.

>
> Best regards,
> Tony.
>>
>>>
>>> A disadvantage is that startup will be a bit slower, since Vim has to
>>> read more directories to find all the files. That's a small price to
>>> pay. Especially if we only do this for some plugins, not all the
>>> distributed ones. That implies that what's under $VIMRUNTIME/bundles is
>>> found first.
>>>
>>> --
>>> Press any key to continue, press any other key to quit.
>>>
>>> /// Bram Moolenaar -- Br...@Moolenaar.net -- 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 ///
>>>
>

[tyru]

Hi Bram,

On Tue, Feb 9, 2016 at 7:03 PM, Bram Moolenaar <Br...@moolenaar.net> 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.

It sounds very interesting and helpful! :)
if a runtime directory is in hand of users.

But there are 3 problems for runtime bundle directory:

1. Runtime plugin must specify the least supported version of Vim

If Vim is too old, required functions for a runtime plugin may not
exist (e.g. shiftwidth()).

2. Need to separate *.vim files into directories, but how should we
separate them?

How can we say *.vim files are "related" in a same directory?
How should we determine the rule?

> That way the directory can be put under version control or updated in
> any other way easily. E.g. unpacking a zip archive that you get from
> Charles's site. And it's also easy to get rid of: delete the directory
> below bundles. No need to hunt down the files that you unpacked before.

3. How should we setup a runtime directory?

Normally, $VIMRUNTIME is under $VIM and it is often unwritable
(especially in has('unix') environment).

Are you thinking that users define $VIMRUNTIME and
copy a runtime directory / make a new runtime directory by himself for
current Vim?

>
> This also makes it easier for plugin managers. No need to keep adding
> more and more entries to 'runtimepath'.
>
> A disadvantage is that startup will be a bit slower, since Vim has to
> read more directories to find all the files. That's a small price to
> pay. Especially if we only do this for some plugins, not all the
> distributed ones. That implies that what's under $VIMRUNTIME/bundles is
> found first.
>
> --
> Press any key to continue, press any other key to quit.
>
> /// Bram Moolenaar -- Br...@Moolenaar.net -- 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 ///
>

[Bram Moolenaar]

Do I understand that the problem is that the name "bundles" is already
used? We could just use another name. It's new so it doesn't really
matter.

> > What about having packages that can be enabled/disabled in some other
> > directory? (let's say $VIMRUNTIME/packages) — which would not be
> > checked for plugins, ftplugins, syntax scripts, keymaps, colorschemes,
> > etc.; then in order to enable package foobar, add in
> > $VIMRUNTIME/bundles a symlink foobar -> ../packages/foobar. Or even
> > simply move packages into and out of bundles/ (and, in this example,
> > out of and into packages) to enable or disable them? (N.B. I'm not
> > sure about modern Windows, but on Linux the "move" operation moves
> > only the directory entry when the directories moved-to and moved-from
> > are in the same filesystem aka the same disk partition.)
>
> I am reporting the current state. There are sure some workarounds (and
> moving directories is not a good one), but still such change will
> break.
>
> Issues with moving directories:
>
> 1. Least significant is that plugins need to be searched in different
> folders (symlinking: when removing a plugin one needs to care about).
> 2. And most significant: you cannot conditionally enable plugin from
> the vimrc for a subset of Vim instances using the same algorythm, so
> why bother writing two algorythms at all? I would just move managed
> plugins from ~/.vim/bundles and ignore new functionality.

I would assume in most cases installed plugins are active. If you do
need to disable one for whatever reason, it should be easy to use a
global variable. Just need a naming scheme. E.g. "disable_plugin_foo".

> I also have forgot one major downside: e.g. my translit3 plugin looks
> for its configuration by iterating over &runtimepath. There are many
> other plugins (especially snippet ones) which do the same thing
> (possibly using globpath(), but e.g. ultisnips iterates over
> &runtimepath). So plugins which contain configuration for such plugins
> (e.g. plugins with snippet collections) cannot be installed the new
> way without being useless.

Why not use <sfile> ? Iterating over runtimepath seems like a last
resort.

> I also saw ultisnips using globpath(&runtimepath, 'syntax/*.vim') for
> whatever reason. This code breaks.

I think it's fairly unusual for a plugin to find all other plugin stuff.
Where that is really needed a solution can be found. In the example,
also use globpath(&runtimepath, 'bundles/*/syntax/*.vim').

> Thus I would say that this idea is bad because it will break plugin
> managers and it will break plugins using globpath(&runtimepath) or
> similar techniques. It is also pointless: a big number of entries in
> &runtimepath does not slow down Vim much compared to the IO from
> iterating over that much directories (which will not change just
> because you use another method for getting a list of directories to
> iterate over), so the only benefit is that user can check that
> something is contained in his &runtimepath easier.

I disagree. If you are using a plugin manager it won't change anything.
Well, the plugin manager may take advantage of the new feature and a few
details may need to be updated. If you don't use a plugin manager then
this feature is a nice way of organising plugins.

--
Some of the well known MS-Windows errors:
EMULTI Multitasking attempted, system confused
EKEYBOARD Keyboard locked, try getting out of this one!
EXPLAIN Unexplained error, please tell us what happened
EFUTURE Reserved for our future mistakes

[Nikolay Aleksandrovich Pavlov]

Yes. But this will not address other points.

I *must not* use <sfile>. User configuration should be in
~/.vim/config. Or ~/.config/vim/config. Or whatever. But *not* in
~/.vim/bundles/translit3/config because it is in a separate repository
that holds a clone of translit3 and config/ there contains default
configuration. As a user I would not want to create translit3 fork
just to hold my configuration.

It is not “last resort”. It is *intentional*. Same for snippets:
plugin that uses snippets, plugin that contains snippets and user
snippets are separate things in different directories in &runtimepath,
in different repositories.

>
>> I also saw ultisnips using globpath(&runtimepath, 'syntax/*.vim') for
>> whatever reason. This code breaks.
>
> I think it's fairly unusual for a plugin to find all other plugin stuff.
> Where that is really needed a solution can be found. In the example,
> also use globpath(&runtimepath, 'bundles/*/syntax/*.vim').

This requires changes to existing code. Until this all plugins using
something like this are broken.

In any case this will make code more complex.

Also needs easy way to test for the feature (like `has('bundles')`,
`has('patch…')` is not readable (purpose of the code is not obvious
from the code)) or they will be broken after.

>
>> Thus I would say that this idea is bad because it will break plugin
>> managers and it will break plugins using globpath(&runtimepath) or
>> similar techniques. It is also pointless: a big number of entries in
>> &runtimepath does not slow down Vim much compared to the IO from
>> iterating over that much directories (which will not change just
>> because you use another method for getting a list of directories to
>> iterate over), so the only benefit is that user can check that
>> something is contained in his &runtimepath easier.
>
> I disagree. If you are using a plugin manager it won't change anything.
> Well, the plugin manager may take advantage of the new feature and a few
> details may need to be updated. If you don't use a plugin manager then
> this feature is a nice way of organising plugins.

If I don’t I can have this be handled by pathogen. The only value that
this feature in core really adds is that I can have nice &runtimepath
and can omit installing pathogen. This is not worth the hassle: I have
saw code iterating over &runtimepath in one way or the other
(globpath() or direct iterations over split) in

1. All snippet plugins I have installed: UltiSnips, neosnippet,
snipmate, xptemplate.
2. Plugins that allow to select something from a list: ku, unite,
neoui, FuzzyFinder, Command-T.
3. Plugins which have plugins*: airline, neocomplcache,
vim-powerline**, syntastic.
4. Some libraries: lh-vim-lib, vial.
5. Other: vim-latex (latex-suite), Threesome, tplugin, PreserveNoEOL,
cuteErrorMarker, vimwiki, viewdoc, Transmit_FTP, VimLint.

Total 24 plugins, 10% of what I have in ~/.vam and I do not have all
existing plugins installed. Some of them are not maintained, but still
usable AFAIK.

* It is not necessary that these plugins iterate over &runtimepath
*because* they have plugins.
** Deprecated old VimL-only plugin, still used by somebody, though
people mostly switched to either airline or Python powerline.

[Bram Moolenaar]

Tyru wrote:

> On Tue, Feb 9, 2016 at 7:03 PM, Bram Moolenaar <Br...@moolenaar.net> 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.
>
> It sounds very interesting and helpful! :)
> if a runtime directory is in hand of users.
>
> But there are 3 problems for runtime bundle directory:
>
> 1. Runtime plugin must specify the least supported version of Vim
>
> If Vim is too old, required functions for a runtime plugin may not
> exist (e.g. shiftwidth()).

That is unrelated to how plugins are organized, the plugin needs to
check for the Vim version and features anyway. E.g. if a plugin
requires Python and there is no Python it can finish.

> 2. Need to separate *.vim files into directories, but how should we
> separate them?
>
> How can we say *.vim files are "related" in a same directory?
> How should we determine the rule?

I don't understand the question. If you get a plugin, either from
github, a .zip file or whatever, you have the files that go into one
directory.

> > That way the directory can be put under version control or updated in
> > any other way easily. E.g. unpacking a zip archive that you get from
> > Charles's site. And it's also easy to get rid of: delete the directory
> > below bundles. No need to hunt down the files that you unpacked before.
>
> 3. How should we setup a runtime directory?
>
> Normally, $VIMRUNTIME is under $VIM and it is often unwritable
> (especially in has('unix') environment).
>
> Are you thinking that users define $VIMRUNTIME and
> copy a runtime directory / make a new runtime directory by himself for
> current Vim?

I was using $VIMRUNTIME as "whatever runtime directory you use". For
Unix it would go under ~/.vim/bundles/... (or whatever name we end up
using for "bundles"). If you are a sysadmin and you want to make the
plugin available for all users you put it under /usr/local/share/
somewhere.

[...]

--
Some of the well known MS-Windows errors:

EMEMORY Memory error caused by..., eh...
ELICENSE Your license has expired, give us more money!
EMOUSE Mouse moved, reinstall Windows
EILLEGAL Illegal error, you are not allowed to see this
EVIRUS Undetectable virus found

[Olaf Dabrunz]

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).


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.

--
Olaf Dabrunz (oda <at> fctrace.org)

[Bram Moolenaar]

Eh, what you are saying here is that it will just keep working, since
user's configuration files will be in 'runtimepath' just like before,
doesn't change.

I meant using <sfile> for the plugin to find other files that come with
it, so they should be in the same directory where the plugin .vim file
is.

> >> I also saw ultisnips using globpath(&runtimepath, 'syntax/*.vim') for
> >> whatever reason. This code breaks.
> >
> > I think it's fairly unusual for a plugin to find all other plugin stuff.
> > Where that is really needed a solution can be found. In the example,
> > also use globpath(&runtimepath, 'bundles/*/syntax/*.vim').
>
> This requires changes to existing code. Until this all plugins using
> something like this are broken.

Most syntax files will still be where they were, so I don't think there
is much that breaks.

We could add an option or command to add all directories found under the
new "bundles" directory to 'runtimepath', sounds like that will make it
work for backwards compatibility.

--
Some of the well known MS-Windows errors:

ETIME Wrong time, wait a little while
ECRASH Try again...
EDETECT Unable to detect errors
EOVER You lost! Play another game?
ENOCLUE Eh, what did you want?

[Nikolay Aleksandrovich Pavlov]

Plugins using globpath() mostly search either for their resources
(like snippets) or their plugins. Plugins to plugins are currently
installed in the same way plugins to Vim are, this (identical
installation process) will break if user chooses to use new
functionality. Syntax files from third-party plugins could not be
found if user chooses to use new functionality. If plugin wants to
verify that certain autoloaded function exists without making Vim run
it or run autoloaded file (I think I saw something like this in
linter) this will break as well.

This resolves issues, but I do not like this:

1. If I correctly understood what you suggest this means that each new
directory will be in turn searched for bundles (or whatever)
subdirectory, which is rather useless.
2. It requires wasting some time on coding this functionality in C,
testing it, etc. Better put pathogen into distribution and be done.


In addition there needs to be created globruntimepath() function in
any case or plugin authors willing to support setups with this option
turned off would have to write complex code. I would welcome this
function regardless of whether or not bundles are implemented though.

---

For updating standard plugins there is another solution: just use git
submodules in vim git repository and make build script put them in the
right location on `make install`. In any case user is highly advised
against doing any changes to installed files after installing any
software, so he is expected to update $VIMRUNTIME as a whole. And for
~/.vim/bundles there are already existing solutions, including for
pathogen (user is expected to work with plugins there as a submodules
and update using appropriate git commands, or he may simply do `for d
in ~/.vim/bundles/* ; do (cd $d && git pull) ; done`).

Even if you do not like submodules there are no problems in organizing
Vim repository to use runtime/bundles (or whatever) and make build
script flatten the whole thing on installation.

[Bram Moolenaar]

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

[Gary Johnson]

Because many plugins _don't_ check for required features or
versions, or complain noisily when they can't run. I have four
checks in my ~/.vimrc that set g:loaded_<plugin> for plugins that
need something I don't always have and that either don't check
themselves, or issue a warning message if they can't run.

Then there's the special case of netrw. I keep a copy of the latest
version under ~/.vim. Trying to use it with a not-too-old version
of Vim gives this error message,

***sorry*** this version of netrw requires vim v7.4 with patch 213

and refuses to let me edit any directories. In this case, I want to
use the version of netrw that's in $VIMRUNTIME for the version of
Vim I'm running. Doing that is fairly easy by putting netrw in its
own directory and putting this rule in my ~/.vimrc:

" The version of netrw installed locally needs vim 7.3.465 or later:"
if v:version > 703 || (v:version == 703 && has("patch465"))
let &rtp = $HOME."/.vim/netrw,".&rtp
endif

(Hmm. I see I need to update that rule.)

The larger point is that adding some sort of bundle directory to
Vim's default 'runtimepath' adds complexity and start-up time to Vim
without solving some of the important problems solved by plugin
managers or by my minimalist plugin management approach. I think a
better solution is to leave 'runtimepath' alone and choose some
existing plugin manager to include with Vim.

Regards,
Gary

[Nikolay Aleksandrovich Pavlov]

Proposed solution is no alternative for plugin manager developers. As
I said this way plugin manager automatically looses ability to
conditionally enable plugins, and this functionality is present in all
modern plugin managers. g:vars to disable plugins defined by plugins
are useless because plugins may not define them. g:vars to disable
plugins parsed by Vim in C code simply add chaos: now plugin developer
that wants to iterate over &runtimepath needs to care about
&runtimepath, &runtimepath/bundles and g:vars.

If you want to get rid of pathogen at this price, this is the way to
go. If you want to get rid of long list of directories in
&runtimepath, then you need something else. Plugin manager popularity
is not going to be affected as well (pathogen is not a plugin
manager). Though I never heard of e.g. Python or lua users complaining
about too long sys.path (package.path/package.cpath), this option is
only checked when some problem like “plugin is not being loaded”
occurs and that is rather rare.

And this was *never* an option that *could* be completely set by user
that is not a Vim developer. Vim may be installed to /usr, /usr/local
or even somewhere under ~. This is reflected by &runtimepath, but it
is not user who determines this, it is package maintainer. Third-party
plugins may go to $VIM/vimfiles or may to whatever was passed to
--with-global-runtime configure define: again on compilation time.
User directory may be $HOME/.vim or $HOME/vimfiles, compilation time
(OS-dependent).

After this user usually adds *one* directory to &runtimepath and
everything else is handled by plugin manager. Or even adds zero
directories, pathogen is fine with being installed as a single file to
~/.vim/autoload. At maximum ~/.vim (and ~/.vim/after) is additionally
replaced by something else.

>
> --
> panic("Foooooooood fight!");
> -- In the kernel source aha1542.c, after detecting a bad segment list
>
> /// Bram Moolenaar -- Br...@Moolenaar.net -- 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 ///
>

[Olaf Dabrunz]

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.

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]

On 10-Feb-16, Olaf Dabrunz wrote:
> 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...

How about giving :finish an optional parameter?

When this is present and greater than zero, the plugin indicates
successful loading, same as when :finish is not invoked by the plugin.

When it is zero, the plugin indicates that it did not load successfully.

And when it is less than zero (the default is -1), then the plugin is
not compatible with this scheme. But probably loading the plugin
failed.

[Bram Moolenaar]

I suggest you contact the author and ask him to fix it. Or, if he
doesn't respond, fork the plugin and publish the fixed version.

I hate it when thousands of users have to work around a problem because
one person forgot something.

I prefer to support well-behaving plugins first, and care much less
about misbehaving ones.

> Then there's the special case of netrw. I keep a copy of the latest
> version under ~/.vim. Trying to use it with a not-too-old version
> of Vim gives this error message,
>
> ***sorry*** this version of netrw requires vim v7.4 with patch 213
>
> and refuses to let me edit any directories. In this case, I want to
> use the version of netrw that's in $VIMRUNTIME for the version of
> Vim I'm running.

I think it is an exception that someone runs older and newer versions of
Vim on one system. Why would you do that?

> Doing that is fairly easy by putting netrw in its
> own directory and putting this rule in my ~/.vimrc:
>
> " The version of netrw installed locally needs vim 7.3.465 or later:"
> if v:version > 703 || (v:version == 703 && has("patch465"))
> let &rtp = $HOME."/.vim/netrw,".&rtp
> endif
>
> (Hmm. I see I need to update that rule.)

Hah! You see, it's easy to say "just put this in your vimrc". People
on this list are power Vim users, and even then they forget about what
they put in their setup months ago. I know I do.

We would be much better off trying to make things "just work" without
tweaks. We should at least try.

> The larger point is that adding some sort of bundle directory to
> Vim's default 'runtimepath' adds complexity and start-up time to Vim
> without solving some of the important problems solved by plugin
> managers or by my minimalist plugin management approach. I think a
> better solution is to leave 'runtimepath' alone and choose some
> existing plugin manager to include with Vim.

Yeah, it has become clear that, because of the lack of support in Vim,
plugin writers and plugin manager writers have used whatever was
available, and now we're stuck in a situation whwere we can't make
improvements without breaking things.

We might need to put the new bundle directories somewhere else, and have
a new option to find them. 'bundlepath'? And when a bundle is used
automatically add it to 'runtimepath'. That might work. But it's
putting the burden on the Vim user...

--
hundred-and-one symptoms of being an internet addict:
210. When you get a divorce, you don't care about who gets the children,
but discuss endlessly who can use the email address.

[Bram Moolenaar]

OK, but this should be an exception and not happen very often. We
should not say "it happens anyway so let's just let plugins mess about".
In other words: plugins should be encourage to make it easier for the
user.

> 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.)

Anything we can do to make it easier for plugin authors? A big
improvement would be if plugins would write tests that we can run
against different Vim configurations. I haven't seen plugins with tests
though...

> 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...

This is for a large part the work of a plugin manager. If you have
dependencies you also need a way to download and install plugins
(otherwise you can only give error messages).

And if plugin writers are so bad at bailing out when it won't work on
the current Vim, you can't really expect them to define dependencies
properly.

> > 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.

I think you are describing a plugin manager.

Right, that's what I was trying to make possible. Sort of a manual
plugin management.

> 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.

I think that's too much for the Vim distribution to support. Unless we
include a plugin manager.

--
hundred-and-one symptoms of being an internet addict:

212. Your Internet group window has more icons than your Accessories window.

[Bram Moolenaar]

We had a discussion before about including a plugin manager in the Vim
distribution, but there was no clear preference. And including one
probably means users of another one will get into trouble because they
interfere or compete.

So my currently plan is to not include a plugin manager, and just let
them do whatever they provide. So I'm not trying to replace them. We
might make their life a bit easier and perhaps make them share common
mechanisms.

Different plugin managers having different ways to enable/disable
plugins is bad, but there probably is no other solution. Vim users will
have to mess with their vimrc.

I also don't think there is a common way for dependencies between
plugins or automatic downloading and updating. That's up to plugin
managers to solve, each in their own different way. I don't like it,
but I also don't know of a solution.

> If you want to get rid of pathogen at this price, this is the way to
> go. If you want to get rid of long list of directories in
> &runtimepath, then you need something else. Plugin manager popularity
> is not going to be affected as well (pathogen is not a plugin
> manager). Though I never heard of e.g. Python or lua users complaining
> about too long sys.path (package.path/package.cpath), this option is
> only checked when some problem like “plugin is not being loaded”
> occurs and that is rather rare.

People usually don't complain anyway for things that are not nice.
Especially if you can make it work if you know how to do it. People are
embarrassed to admit they didn't know something. Counting complaints is
a very tricky way of deciding what to do.

> And this was *never* an option that *could* be completely set by user
> that is not a Vim developer. Vim may be installed to /usr, /usr/local
> or even somewhere under ~. This is reflected by &runtimepath, but it
> is not user who determines this, it is package maintainer. Third-party
> plugins may go to $VIM/vimfiles or may to whatever was passed to
> --with-global-runtime configure define: again on compilation time.
> User directory may be $HOME/.vim or $HOME/vimfiles, compilation time
> (OS-dependent).

Sure, anything can do anything. But the option was meant to be under
control of the user. So if the package maintainer adds something, the
user can remove that. Things got out of hand because plugin managers
didn't have another way to do what they wanted to do, so they took over
the option.

> After this user usually adds *one* directory to &runtimepath and
> everything else is handled by plugin manager. Or even adds zero
> directories, pathogen is fine with being installed as a single file to
> ~/.vim/autoload. At maximum ~/.vim (and ~/.vim/after) is additionally
> replaced by something else.

I don't change runtimepath often, but when I do it's usually to remove
something I don't want.

--
hundred-and-one symptoms of being an internet addict:

211. Your husband leaves you...taking the computer with him and you
call him crying, and beg him to bring the computer back.

[Luc Hermitte]

Hi,

> Anything we can do to make it easier for plugin authors? A big
> improvement would be if plugins would write tests that we can run
> against different Vim configurations. I haven't seen plugins with
> tests though...

There are a few plugins doing automated tests. And of course, each has taken a different path.

For instance, I have a few plugins with automated tests. See for instance lh-cpp: https://github.com/LucHermitte/lh-cpp which has both unit tests that can fill quickfix window and more elaborated tests where I check what the buffer contains after the commands I execute.

https://github.com/kana/vim-vspec provides another framework for testing plugins.

My biggest issue is related to feedkey() that I wasn't able to use through --remote-expr to trigger omni-completion. I had to find other way to test my snippets.

Regards
--
Luc Hermitte

[Bram Moolenaar]

Luc Hermitte wrote:

> > Anything we can do to make it easier for plugin authors? A big
> > improvement would be if plugins would write tests that we can run
> > against different Vim configurations. I haven't seen plugins with
> > tests though...
>
> There are a few plugins doing automated tests. And of course, each has
> taken a different path.
>
> For instance, I have a few plugins with automated tests. See for
> instance lh-cpp: https://github.com/LucHermitte/lh-cpp which has both
> unit tests that can fill quickfix window and more elaborated tests
> where I check what the buffer contains after the commands I execute.
>
> https://github.com/kana/vim-vspec provides another framework for
> testing plugins.

I hope we can get plugin authors together and make a recommendation.

> My biggest issue is related to feedkey() that I wasn't able to use
> through --remote-expr to trigger omni-completion. I had to find other
> way to test my snippets.

I also had a problem writing a test for something that tries to
reproduce what a user types. It didn't really work (Vim sees typeahead
and does something else). We might need to support something in Vim
itself to support these tests. Making testing easier is a good goal.

--
hundred-and-one symptoms of being an internet addict:

215. Your mouse-clicking forearm rivals Popeye's.

[Gary Johnson]

On 2016-02-10, Bram Moolenaar wrote:

> I think it is an exception that someone runs older and newer versions of
> Vim on one system. Why would you do that?

At home, I have a couple of older Linux systems on which I run the
distribution's Vim package rather than build my own. I don't use
Vim often enough or heavily enough on those systems for me to bother
to build my own version on them, but I do really like having the
settings I'm used to and it is easy enough to keep my ~/.vim
directories in sync across all the machines I use, so I do.

At work, we all have home directories that are automatically NFS
mounted to whatever Linux machine we log on to. I maintain my own
Vim on my primary machine, but it doesn't even run on some of the
older Linux machines, so I use whatever Vim version is there, which
may be old or not full-featured.

There were other comments in your reply that deserve a response, but
they require more thought than I have time to give at the moment.

Regards,
Gary

[Gary Johnson]

On 2016-02-10, Bram Moolenaar wrote:

In some of these cases, the plugin is not broken. It correctly
detects that it is unable to function and correctly (in my view)
prints a warning to the user including the reason it can't function.

I like seeing that message. Once. Then I put a test in my ~/.vimrc
so that I don't have to see it every time I run that version of Vim.

If the plugin needs fixing, then you're right, the correct thing to
do is to contact the author, and probably to put the fix in your
local copy of the plugin until the author publishes the fix.

Forking the plugin, however, is a much bigger commitment than simply
supplying a patch, and more than most people are willing to do.
Besides publishing the fork, you have to deal with the stream of
e-mail from people who can't get it to work, want you to change or
add just this one little feature, or who have a patch themselves to
change or add something.

Sometimes I just want to get the darned thing working so that I can
get on with using it to do my real job. I appreciate Vim having the
flexibility to allow me to do that easily. I add a few lines of
code to my ~/.vimrc or to the plugin, the problem is fixed, and I
can forget about it.

> I hate it when thousands of users have to work around a problem because
> one person forgot something.
>
> I prefer to support well-behaving plugins first, and care much less
> about misbehaving ones.

Yeah, but it's nice to be able to use the misbehaving ones when, in
spite of their imperfections, they do the job.

Regards,
Gary

[tyru]

On Thu, Feb 11, 2016 at 2:00 AM, Bram Moolenaar <Br...@moolenaar.net> wrote:

> Keep in mind that the plan is to keep the distributed files where they
> are. This is only for when you want the latest version, or something
> that is not part of the distributed files.

Oh, I have mistaken this.
I got it.

> We might need to put the new bundle directories somewhere else, and have
> a new option to find them. 'bundlepath'? And when a bundle is used
> automatically add it to 'runtimepath'. That might work. But it's
> putting the burden on the Vim user...

I also like this idea.
Maybe it enables to do ZyX's conditional plugin loading, too.

Or, let 'runtimepath' support wildcard, like:

set rtp+=~/.vim/bundle/*

This helps to add plugins more easily.
But it doesn't avoid to load specific plugins in above plugins (in
other words, blacklist feature).

set rtp+=~/.vim/bundle/*,!~/.vim/bundle/pluginA

However, I think this demand applies 'bundlepath' option, too.


--
Takuya Fujiwara

[Olaf Dabrunz]

Yes, this should be an exception (in my case for 18% of the plugins,
mostly for code snippet plugins and their libraries), and yes, we should
definitely encourage plugins to get their feature and version checks
right.

In my suggestion to load plugins according to a dependency graph, the
graph will mostly be empty, and Vim will load the plugins just as it
used to do it, letting the plugins decide if they can load successfully.

For the cases where fallbacks need to be specified, Vim will still
attempt to load plugin A, and only if that fails it will attempt to load
plugin B. So decisions are still based on the plugin's go/no go
assessment.

Yes, this is part of a plugin manager.

Plugin managers currently use &runtimepath to implement conditional
loading of plugins, based on conditions specified by the user.

If we want to clean up &runtimepath, and take fallback actions (that is,
load other plugins) based on the failure or success of loading plugins,
we need some other way to specify the fallbacks to Vim.

If we don't offer some other way to specify fallbacks, and to
disable/enable plugins, plugin managers will continue to resort to using
&runtimepath.

Using &runtimepath means the decision to load A or B and C has to be
made when &runtimpath is set up, which is before plugin loading is
attempted. So in fallback cases the user has to figure out and specify
the conditions when to load each plugin.

Which is something I would like to change. Let Vim load A, and only if
that fails load B and C.

Admittedly, fallback handling is not needed in many cases. But what can
plugin managers do except for using &runtimepath to cover such cases?

Please see below for a suggestion.

Hm, I was also thinking that it may be too much. Maybe it is.


Here is an idea of what it would look like:

Vim can remember the success of loading a plugin in
v:scripts[<scriptname>]. This stores the value the plugin has given
with :finish <value>.

Typically 0 or 1, -1 if no value was given, and -2 if the plugin did
not execute :finish. (A plugin can only specify values >= 0.)

This should cover most current uses of :finish correctly, and gives
plugins a way to be exact about loading successfully in the future.
Special (legacy) cases can be dealt with by plugin managers, please
see below.

<scriptname> is the full path name of the plugin.

Additionally, there are indices for the plugin base names, that is
the names without path and without trailing .vim:

v:scripts[<basename>] = ['<scriptname1>', '<scriptname2>', ...]

(There can be no collisions, <basename> cannot contain path
separators, <scriptname> must contain at least a leading path
separator.)

In .vimrc, the user can say

:plugdep "<basename>" "<condition>" or
:plugdep "<scriptname>" "<condition>"

and the condition can use the v:scripts dictionary, or just 0.

The "<condition>" is eval()'ed by Vim before Vim tries to load the
plugin <scriptname>. If the result is false, Vim skips the plugin.

Plugins with dependencies are considered last, and in the order of the
:plugdep commands.

Example:

:function PluginLoaded(name)
: " ':finish' -> not loaded, no ':finish' -> loaded
: " (and below: ':finish <value>' -> loaded if <value> > 0)
: let loaded = {-1: 0, -2: 1}
: if !has_key(v:scripts, a:name)
: return 0 " unknown -> not loaded
: endif
: let val = v:scripts[a:name]
: if type(val) == type(1)
: " a:name is full plugin path
: return get(loaded, val, val) > 0
: endif
: " plugin basename: has loaded if loaded from any path
: return max(
: \ map(val, 'get(loaded, v:scripts[v:val], v:scripts[v:val])')
: \ ) > 0
:endfunction
:
:plugdep 'vim-addon-mw-utils' '!PluginLoaded("ultisnips")'
:plugdep 'tlib_vim' '!PluginLoaded("ultisnips")'
:plugdep 'vim-snipmate' '!PluginLoaded("ultisnips")'
:
:plugdep 'test_me' '0' " disabled


Example for netrw (Gary):

:plugdep $HOME.'/.vim/plugin/netrwPlugin.vim'
: \ 'v:version > 703 || (v:version == 703 && has("patch465"))'
:plugdep 'netrwPlugin' '!PluginLoaded("netrwPlugin")'

netrw always sets its g:loaded_netrwPlugin variable, even if it does
not load successfully. If it would set g:loaded_netrwPlugin only
when loading successfully, then several attempts could be made to
try loading different versions of it, and we would only need to
specify order of precedence here (= order of :plugdep commands):

:plugdep $HOME.'/.vim/netrw/netrwPlugin.vim' '1'
:plugdep 'netrwPlugin' '1' " or '!PluginLoaded("netrwPlugin")'

And maybe there should be a way to suppress netrw's error message
for unsuccessful loads.


Too much, maybe. But maybe not?

There still is the assumption that ':finish' (without value) means 'not
loaded'. But that's usually true, and where it is not, the plugin
manager can make a list of such plugins and use special checks on the
plugin's g:..._loaded variables (in the PluginLoaded() function).

With this in place, I believe &runtimepath does not need to be changed
by plugin managers.

And in all cases the decision of whether a plugin loads successfully is
left to the plugin to decide. Unless the user *really* wants to
override this.

[Bram Moolenaar]

Hmm, I didn't intend to replace a plugin manager, but assuming that the
user doesn't have one, or the plugin isn't made to be used by one, it
would be nice if the plugin writer can say "load this other plugin".
And that other plugin would then only be loaded when being asked to.

So, besides the "plugin bundles" that would always be loaded when found,
we could have "optional bundles" that are only loaded on request.

This would then also fulfill your ask for loading a plugin depending on
some conditions, from your .vimrc:
if some_condition
loadplugin thatPlugin
endif

I know some plugin writers have debugging stuff that is only enabled
when being asked for. So they could do something like:

if g:xxx_want_debug
" try loading plugin with XxxDebug command, may fail if the
" plugin can't be found.
loadplugin xxxdebug
endif

if exists(':XxxDebug')
XxxDebug "got there"
endif

Obviously there is no automatic downloading or updating. And it raises
the question of how the optional plugins are made available. One can
assume they are used by more than one plugin by the same author. Would
be nice if you can update them all at once... Can't think of a solution
that doesn't add another directory level (bundle of bundles). Perhaps
not go that way.

Yeah, I think I've given up on cleaning up 'runtimepath'. I don't think
I make users happy by breaking their snippets plugin or plugin manager.
I might be able to convince authors of plugin managers to change how it
works, but there will be users who upgrade Vim without updating the
plugin manager.

So we probably have to accept that 'runtimepath' is a mess and find
another solution.

I think this is expecting too much of plugin authors. Too many things
to understand, too many mistakes that can be made.

It should not use the whole path, only the name of the plugin. The user
may install plugins in several directories. There can be system-wide
plugins with per-user override (that's what I have at work).

We can keep track of which plugins we tried to load. Whether that
succeeded or not is already getting a bit tricky, it depends on the
plugin writer. The load could also work partially.

One thing we know: If one plugin depends on another plugin, it knows why
it depends on it. So it can check if loading that plugin worked by
checking for that dependency. Above I used a user command as an
example.

Perhaps all we need is:
- 'pluginpath' - list of directories that contain plugin bundles that
are always loaded. User puts them there.
- 'optionalpluginpath' - list of directories that contain plugin bundles
that can be loaded when wanted (needs a better name).
- ":loadplugin" - loads an optional plugin and remembers that Vim tried
to load it, won't load it a second time.

When loading a plugin from 'pluginpath' or 'optionalpluginpath' that
directory is added to 'runtimepath'. That hopefully keeps existing
plugins and plugin managers working.

--
hundred-and-one symptoms of being an internet addict:

227. You sleep next to your monitor. Or on top of it.

[Bram Moolenaar]

I wrote:

[...]

> Perhaps all we need is:
> - 'pluginpath' - list of directories that contain plugin bundles that
> are always loaded. User puts them there.
> - 'optionalpluginpath' - list of directories that contain plugin bundles
> that can be loaded when wanted (needs a better name).
> - ":loadplugin" - loads an optional plugin and remembers that Vim tried
> to load it, won't load it a second time.
>
> When loading a plugin from 'pluginpath' or 'optionalpluginpath' that
> directory is added to 'runtimepath'. That hopefully keeps existing
> plugins and plugin managers working.

An alternative would be:
- 'bundlespath' defines where to search for bundles, the default would
be the same as the 'runtimepath' default.
- Below the runtime directory, besides syntax, indent, etc. there would
be two more directories:
"bundledef" - default plugins, loaded on startup
"bundleopt" - plugins loaded with ":loadplugin"

Main disadvantage is still that distributing a plugin with its optional
dependencies end up in multiple directories, can't be a git clone or
unpacking one zip archive. Would still need another directory level to
solve that. E.g. when netrw is a default plugin that may load nwdebug:
~/vim/packages/netrw/def/netrw/plugin/netrw.vim
~/vim/packages/netrw/def/netrw/syntax/netrw.vim
~/vim/packages/netrw/opt/nwdebug/plugin/nwdebug.vim

When found it would add ~/vim/packages/netrw/def/netrw to 'runtimepath'.
And when nwdebug gets used also ~/vim/packages/netrw/opt/nwdebug.

Not sure if I like this...

--
hundred-and-one symptoms of being an internet addict:

228. You spend Saturday night making the counter on your home page
pass that 2000 mark.