2016-02-10 0:53 GMT+03:00 Bram Moolenaar <[email protected]>:
>
> 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.
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 -- [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.
--
--
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.
