Learning GNU Emacs, 3rd Edition

Appendix C. Bugs and Bug Fixes

There are no perfect programs. GNU Emacs is very thoroughly debugged, but it is certainly possible to find things that don't work correctly.

The Free Software Foundation (FSF) welcomes problem reports. However, they need to be real problem reports; simple differences of opinion about how something should work are not bugs. If you think that a certain command should work differently, remember that Emacs has been around for a long time and has many users; it can't be changed to satisfy a single user. (On the other hand, in most cases, you could write some Lisp to change it yourself.) In the GNU Emacs Manual, the FSF publishes some excellent guidelines for reporting bugs, which we'll summarize very quickly:

• Before you report a bug, see if it's on the list of known problems. You can view this list by typing C-h C-e.

• You most certainly have a bug if you run into some kind of system error (Emacs dumps core, terminates with a segmentation fault, crashes, hangs, or does something else antisocial).

• When reporting bugs, be as specific as possible. A few commands will help you report exactly what was happening when things went awry. C-h l (for view-lossage) reports the last 100 or so keystrokes you made; M-x open-dribble-file filename saves every keystroke you type in the specified filename.

• The FSF discourages you from trying to interpret bugs in the bug report. "I did thus-and-such and this happened" is useful, particularly if the problem is repeatable; "I think ...