Nikolay Pavlov wrote:
> 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.
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.
/// 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.
