Creating a generic response for debugging init files

Question

I've noticed a common theme in questions that are really about how to debug user init files. Examples:

• "S" key throws error in Evil mode normal state
• Certain symbols resulting in really tall line (and cursor)
• Emacs keeps highlighting the word 'fix' in every context - how do I turn it off?

And likely many others. I'm wondering if we should have a default FAQ or something to link to if the question seems to be actually focused on how to debug emacs init files as a whole, and not necessarily related to the specific problem they are asking about.

Topics that might be useful would be:

• emacs --debug-init
• debug-on-error
• debug-on-quit
• emacs -Q
• minimal init files with package initialization to use with emacs -Q -l minimal-init.el
• how to selectively load new packages into the minimal init until the problem re-appears.

I think it might be useful to tag questions like this with debug-init and possibly add the default answer on the tag help?

I realize that init-file is already covering some of this, but seems more targeted at questions like Emacs won't load theme on startup, then the examples above?

Answer 1

You forgot one, which I find myself adding as a comment (and sometimes an answer) quite often:

• Recursively bisect your init file until you locate the problematic code.

And I mention that you can do that by commenting out 1/2 of it, then 3/4, 7/8, 15/16, 31/32, 63/64, 127/128, 255/256, 511/512,... I mention that you can use comment-region to comment out a region, and use C-u with comment-region to uncomment a region. (People can disagree about whether comment-dwim is as good for uncommenting, but it is certainly an alternative.)

This simple tool is very effective (after determining, using emacs -Q, that the init file is problematic).

This is not obvious, even if we think it should be. I think we all tend naturally to think that we can smart-it-out, reasoning and guessing, to try to narrow things down more quickly than could be done by a systematic, blind, dumb, binary search. And sometimes we can. And sometimes we fool ourselves.

I know that I had to learn this lesson over and over. Like many others, I have a large init file, which loads many libraries etc. I've learned my lesson - but it did take a while: Let Mr. Binary Search do the hunting - there will be enough time for thinking once you find the problematic code. ;-)

Answer 2

This sort of thing is best handled by a “canonical question”: a question asking about a generic scenario (I have a problem due to something in my init file, how can I find out what's causing it?), with an answer (or several answers) covering the main cases and techniques. This question can be used as a duplicate target for closure and can also be used as a reference in comments and answers about the topic.

Using a question/answer pair is better than putting the information in a tag wiki because Q/A pairs are more visible (they turn up in searches, they're suggested when composing a title or a post body, etc.) and can be used as duplicate targets. The relevant tag wiki(s) (here, init-file and debugging) should contain a link to the question.

Beware that getting a canonical question right can be tricky. There's a delicate balance between making the question and answers sufficiently widely applicable to be useful, and making them so general that the reader is drowned in information that isn't relevant to their situation.

Answer 3

Could we adopt some of the TeX.SE norms about minimal examples? Maybe it should be acceptable to comment "Please post a minimal init" when the question seems to need it.

Meta.TeX.SE: I've just been asked to write a minimal example, what is that?