How to include .vimrc for analyze?

Question

When people have issue where Vim is not working as expected the root cause can (often) be tracked back to .vimrc (or an outdated / buggy plugin). As people often do not know which part of the rc file is at fault, they think they know, but are wrong, etc. I guess some way to include the users rc file could be looked at.

However, as these files can be rather big, it is in danger of cluttering up the question. Question is if there should / could be some sort of include feature. Typically either:

1. Some way to add the file as an attachment. (Typically a line at bottom of question with a link to a paste-like site, or as direct attachment - (served as text file so that one can open directly in browser).
2. Something like the collapsible code blocks on StackOverflow. “Click to view”
3. Some other / better way ...

I am not sure how much this is going to be an issue. Depends largely on how many of these questions one get.

Without the config file one could end up with (a lot?) of questions where one have a wall of comments like; “Do you have this in your .vimrc”?, “Do you have that in you .vimrc”, and answers taking the form of “If you have this or that in your .vimrc or that and this is in wrong order or ... that could explain what you see.”

Would such a feature be in good? If so, then what format?

---

Edit:

My thought was more in the lines of what mentioned by aharris88 plus various. But more thought on the topic, and a Q/A here – and a read-trough on questions posted thus far, I believe the issue is close to being unemployed.

Not saying it won't arise as a valid issue, but can't, thus far, see a valid reason for leaving this open. As such I accept the highest voted and leave it there.

To emphasize; read: How do I debug my vimrc file?

Answer 1

I don't think we need to address the issue; I don't think "debug my configuration for me" questions are on-topic.

There's probably room for one question, along the lines of "What technique should I use to diagnose a problem in my .vimrc?" We don't need tons of "What is wrong with this specific .vimrc questions," they aren't ever going to be helpful to future visitors and they're all going to involve effectively the same answer.

Answer 2

Debugging which part of a vimrc file is problematic is a very basic operation: you simply comment a part out, see if the problem persists, if it does, repeat.

My mother could do it while drunk. There is no need to post a gazillion-line vimrc file with the question "it no work. plz debug for me. kthxbye".

It is, of course, perfectly fine to post a reasonably small snippet and ask "I expect this to do X, but instead it does Y, what gives?".

If you see a question, and suspect that the fault is in the OP's vimrc file, ask them to start it with -u NONE or -U NONE to prevent loading it. Does the problem disappear? Ask the user to locate the problematic part/plugin his/herself.

Answer 3

I don't think people should be asking questions that are basically "debug my vimrc for me", but I think it's alright to post a link to the vimrc, just in case someone wants to check it out and just in case the solution might be something unexpected.

Also, I believe that when linking to the vimrc, you should link to the current version of the vimrc, by either linking to a gist that won't change, or the vimrc on a specific commit on github. Example, this:

https://github.com/aharris88/dotfiles/blob/b7128b10b038229c564f48a4280096a856aa650b/vim/vimrc

not this:

https://github.com/aharris88/dotfiles/blob/master/vim/vimrc