On 2016-02-10, Bram Moolenaar wrote:
> 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.
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
--
--
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.
