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 [email protected]. For more options, visit https://groups.google.com/d/optout.
