53.3 Understanding Bug Reporting

When you decide that there is a bug, it is important to report it, and to report it in a way which is useful. What is most useful is an exact description of what commands you type, starting with the shell command to run Emacs, until the problem happens, and the effects produced by typing those commands.

The most important principle in reporting a bug is to report facts. Hypotheses and verbal descriptions are no substitute for the detailed raw data. Reporting the facts is straightforward, but many people strain to posit explanations and report them instead of the facts. If the explanations are based on guesses about how Emacs is implemented, they might not be useful; meanwhile, lacking the facts, we will have no real information about the bug. If you want to actually debug the problem, and report explanations that are more than guesses, that is useful—but please include the raw facts as well.

For example, suppose that you type C-x C-f /glorp/baz.ugh RET, visiting a file which (you know) happens to be rather large, and Emacs displays ‘I feel pretty today’. The bug report would need to provide all that information. You should not assume that the problem is due to the size of the file and say, “I visited a large file, and Emacs displayed ‘I feel pretty today’.” This is what we mean by “guessing explanations”. The problem might be due to the fact that there is a ‘z’ in the file name. If this is so, then when we got your report, we would try out the problem with some large file, probably with no ‘z’ in its name, and not see any problem. There is no way we could guess that we should try visiting a file with a ‘z’ in its name.

You should not even say “visit a file” instead of C-x C-f. That’s because a file can be visited in more than one way, and there’s no certainty that all of them reproduce the problem. Similarly, rather than saying “if I have three characters on the line”, say “after I type RET A B C RET C-p”, if that is the way you entered the text—that is, tell us about the text which in your case produced the problem.

If possible, try quickly to reproduce the bug by invoking Emacs with emacs -Q (so that Emacs starts with no initial customizations; see Initial Options), and repeating the steps that you took to trigger the bug. If you can reproduce the bug this way, that rules out bugs in your personal customizations and makes the bug much easier to reproduce. Then your bug report should begin by stating that you started Emacs with emacs -Q, followed by the exact sequence of steps for reproducing the bug. If possible, inform us of the exact contents of any file that is needed to reproduce the bug.

Some bugs are not reproducible from emacs -Q; some are not easily reproducible at all. In that case, you should report what you have—but, as before, please stick to the raw facts about what you did to trigger the bug the first time.

If you have multiple issues that you want to report, please make a separate bug report for each.