Gary Johnson wrote:
> On 2016-02-09, 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 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.
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 -- [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.
