6

I'm seeing a spate* of questions where users ask a (sometimes very simple) question and then paste their entire .vimrc in.

I guess it's possible that for some issues this might help to narrow down the problem, but generally this doesn't seem to be the case, and I have a gut feeling that this isn't really something that we want on the site. (Related: How to include .vimrc for analyze?)

Do other people agree that this is not ideal, or does anyone think that actually this is a good thing?

Is there anything in particular that we should do about it?

Would it be appropriate to edit out the .vimrc once the problem has been solved? What about if the problem hasn't been solved?

Should we just point the user to the .vimrc debugging question? Delete the .vimrc and direct the user there?

* Possibly a slight exaggeration: there's at least a couple.

| |
10

I think a lot of it depends on context. On one hand, it's a good thing that the OP is providing plenty of detail for potential answerers. On the other hand, it reeks of laziness and a lack of attempting to fix the problem for themselves.

For example, questions like this:

Vim does X but I want it to do Y. Here is my .vimrc:

"400 lines of vimscript

are very low-quality. These deserve a downvote and probably also a unclear what you're asking vote.

But a question like this:

Vim does X but I want it to do Y. I'm pretty sure it has to do with my foo and bar settings. I have this in my .vimrc:

set foo=x
set bar=y

but I can't figure out the correct setting or what the problem is. For reference, here is the rest of my .vimrc: (a link to a github gist)

is a fantastic question. It is:

  • Minimal – The two lines of set foo and set bar are a very helpful and minimal example that will help answerers know what you're talking about and what to look for. That is, assuming the two lines are enough to reproduce the problem.

  • Complete and Verifiable - It provides enough detail to test any part of the OPs configuration if you want to. This is a good thing. Of course, posting the entire .vimrc into the question itself is annoying, I would highly recommend not doing this. A link is much more useful/user friendly.

With this in mind, I'd propose the following guidelines:

  • An external link to a .vimrc never hurts. At best, it can be the crucial missing details that someone needs to answer your question, and at worst it's a link that never gets clicked. However...

  • A question should always be answerable with either no .vimrc, or a minimal example from the .vimrc that recreates the problem. If you want someone to take time out of their day to answer your question, you must be willing to take some time out of your day to prune away the irrelevant parts of your configuration, and in the process it's very likely you'll find out which line is causing your problem.

    If you do not identify a specific feature or problem that you want to change, the question should be closed as Too broad.

  • If you have to slog through an entire .vimrc file to find the relevant settings, the question is unclear, and should be closed as such.

On a side note, nobody is perfect. In general, if you're asking a question here, it's because there's something in your .vimrc that you don't understand. Otherwise you wouldn't be asking the question in the first place!

I don't expect everyone who asks a question to know exactly which line is causing them issues. If you happen to include an extra couple lines that are irrelevant, that's not an unforgivable sin. As long as the posted lines are shorter than a paragraph or two and accurately reproduce the problem, you're fine.

The important part is that you show you have gone to the effort of trimming away enough of your file to make the question easily answerable.

| |

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .