The best way to send a bug report is to mail it electronically to the Emacs maintainers at `firstname.lastname@example.org'. (If you want to suggest a change as an improvement, use the same address.)
If you'd like to read the bug reports, you can find them on the newsgroup `gnu.emacs.bug'; keep in mind, however, that as a spectator you should not criticize anything about what you see there. The purpose of bug reports is to give information to the Emacs maintainers. Spectators are welcome only as long as they do not interfere with this. In particular, some bug reports contain large amounts of data; spectators should not complain about this.
Please do not post bug reports using netnews; mail is more reliable than netnews about reporting your correct address, which we may need in order to ask you for more information.
If you can't send electronic mail, then mail the bug report on paper or machine-readable media to this address:
GNU Emacs Bugs Free Software Foundation 59 Temple Place, Suite 330 Boston, MA 02111-1307 USA
We do not promise to fix the bug; but if the bug is serious, or ugly, or easy to fix, chances are we will want to.
A convenient way to send a bug report for Emacs is to use the command M-x report-emacs-bug. This sets up a mail buffer (see section Sending Mail) and automatically inserts some of the essential information. However, it cannot supply all the necessary information; you should still read and follow the guidelines below, so you can enter the other crucial information by hand before you send the message.
To enable maintainers to investigate a bug, your report should include all these things:
configurecommand when Emacs was installed.
(open-dribble-file "~/dribble")using M-: or from the `*scratch*' buffer just after starting Emacs. From then on, Emacs copies all your input to the specified dribble file until the Emacs process is killed.
TERM), the complete termcap entry for the terminal from `/etc/termcap' (since that file is not identical on all machines), and the output that Emacs actually sent to the terminal. The way to collect the terminal output is to execute the Lisp expression
(open-termscript "~/termscript")using M-: or from the `*scratch*' buffer just after starting Emacs. From then on, Emacs copies all terminal output to the specified termscript file as well, until the Emacs process is killed. If the problem happens when Emacs starts up, put this expression into your `.emacs' file so that the termscript file will be open when Emacs displays the screen for the first time. Be warned: it is often difficult, and sometimes impossible, to fix a terminal-dependent bug without access to a terminal of the type that stimulates the bug.
(setq debug-on-error t)before the error happens (that is to say, you must execute that expression and then make the bug happen). This causes the error to run the Lisp debugger, which shows you a backtrace. Copy the text of the debugger's backtrace into the bug report. This use of the debugger is possible only if you know how to make the bug happen again. If you can't make it happen again, at least copy the whole error message.
-qswitch to prevent loading the init file). If the problem does not occur then, you must report the precise contents of any programs that you must load into the Lisp world in order to cause the problem to occur.
prto print the Lisp object in Lisp syntax. (If you must use another debugger, call the function
debug_printwith the object as an argument.) The
prcommand is defined by the file `.gdbinit' in the `src' subdirectory, and it works only if you are debugging a running process (not with a core dump). To make Lisp errors stop Emacs and return to GDB, put a breakpoint at
Fsignal. To find out which Lisp functions are running, using GDB, move up the stack, and each time you get to a frame for the function
Ffuncall, type these GDB commands:
p *args prTo print the first argument that the function received, use these commands:
p args prYou can print the other arguments likewise. The argument
Ffuncallsays how many arguments
Ffuncallreceived; these include the Lisp function itself and the arguments for that function. The file `src/.gdbinit' includes several other commands that are useful for examining the data types and contents of Lisp objects. These commands work at a lower level than
pr, and are less convenient, but they may work even when
Here are some things that are not necessary in a bug report:
Go to the first, previous, next, last section, table of contents.