Quantcast

How to determine what a "bare-bones" vim is for a plugin

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

How to determine what a "bare-bones" vim is for a plugin

'Suresh Govindachar' via vim_use

Hello,

Some plugin authors understandably require that any issue reports to be
reproducible on a "bare-bones" vim.  But that plugin might be requiring
a vim that has more capabilities than one started with "gvim -u none -U
NONE".  As an example, fugitive.vim is inoperable in such a gvim, and
silently so (no error messages).

So, in general, given a plugin, how does one determine what is the
"bare-bones" vim it's author has assumed?

Thanks,

--Suresh

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to determine what a "bare-bones" vim is for a plugin

hermitte
Hi,

> Some plugin authors understandably require that any issue reports to
> be reproducible on a "bare-bones" vim. [...]
>
> So, in general, given a plugin, how does one determine what is the
> "bare-bones" vim it's author has assumed?

As a plugin author, I find legit issues related to incompatibilities with other plugins. However, I do need to know what other plugins are installed. Even better if you (end-user) are able to determine which plugin is incompatible with mine, it's even better.
First because this will permit me to quickly converge to a solution. But also this will permit me to make sure: either this won't happen again, or this will permit me to add a few words on the subject in my plugin documentation.

However, if the issue is related to `:map-<unique>`, well I'd rather see my end-users aware able to solve this by themselves, but yet I know that sometimes I need to explain them what they can do.

What you need to see, is that most of us expect you to investigate by yourself what causes the issue, or what scenario permits to reproduce it. In other words, it's your job to determine the Minimum Working Example. From there if you're able to say "setting xxx" or "installing yyy" cause incompatibilities, well you'll have done a good job. One from which we could work efficiently on your issue.
Of course, the issue could be completely unrelated to other plugins... That's where the exact scenario that permits to reproduce the issue is important.

--
Luc Hermitte

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to determine what a "bare-bones" vim is for a plugin

Christian Brabandt
In reply to this post by 'Suresh Govindachar' via vim_use
Hi 'Suresh!

On Fr, 17 Mär 2017, 'Suresh Govindachar' via vim_use wrote:

> Some plugin authors understandably require that any issue reports to
> be reproducible on a "bare-bones" vim.  But that plugin might be
> requiring a vim that has more capabilities than one started with
> "gvim -u none -U NONE".  As an example, fugitive.vim is inoperable
> in such a gvim, and silently so (no error messages).
>
> So, in general, given a plugin, how does one determine what is the
> "bare-bones" vim it's author has assumed?

As maintainer of vim-airline that is totally understandable and I
request the same if the bug is not reproducible for me. It happened to
often that someone comes over, stating "I started using Vim 1 month ago,
installed vim-spf13 and when switching buffers airline is not
refreshed."

I expect a litte more from the bug reporter, e.g. trying to reproduce
this with a sane minimal configuration, as I am not going to debug a
multi thousands line vim configuration.

Best,
Christian
--
Wenige Dinge auf Erden sind lästiger als die stumme Mahnung, die von
einem guten Beispiel ausgeht.
                -- Mark Twain (eigl. Samuel Langhorne Clemens)

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Loading...