mly@mit-prep (07/09/85)
From: Richard Mlynarik <mly@mit-prep>
I quote from etc/DISTRIB, which recipients of GNU Emacs are requested
to read:
"If you are on the Internet, report bugs to bug-gnu-emacs@mit-prep.
On Usenet, use the address ...!ucbvax!bug-gnu-emacs%mit-prep."
People have been cluttering the lusenet net.emacs newsgroup with bug
reports about GNU Emacs for which the above addresses are far more
appropriate. I have heard many people complain about the amount of
junk mail posted to net.* --- surely one way to cut down on this is to
use one's brain and send messages to appropriate mailing lists when
they exist.
Also, bug-gnu-emacs is read by a larger number of people and far more
frequently than the low signal/noise net.emacs input, and so bug
reports sent to the former address will be responded to much faster
and more directly.
The following is paraphrased from RMS' ITS Emacs manual -- please try
to heed it:
Reporting Bugs
==============
Sometimes you will encounter a bug in Emacs. To get it fixed, you
must report it. It is your duty to do so; but you must know when to
do so and how if it is to be constructive.
When Is There a Bug
-------------------
If Emacs executes an illegal instruction, or dies with an operating
system error message that indicates a problem in the program (as
opposed to "disk full"), then it is certainly a bug.
If Emacs updates the display in a way that does not correspond to what
is in the buffer, then it is certainly a bug. If a command seems to
do the wrong thing but the problem is gone if you type C-L, then it is
a case of incorrect display updating.
Taking forever to complete a command can be a bug, but you must make
certain that it was really Emacs' fault. Some commands simply take a
long time. Quit or restart Emacs and type Help L to see whether the
keyboard or line noise garbled the input; if the input was such that
you KNOW it should have been processed quickly, report a bug. If you
don't know, try to find someone who does know.
If a command you are familiar with causes an Emacs error message in a
case where its usual definition ought to be reasonable, it is probably
a bug.
If a command does the wrong thing, that is a bug. But be sure you
know for certain what it ought to have done. If you aren't familiar
with the command, or don't know for certain how the command is
supposed to work, then it might actually be working right. Rather
than jumping to conclusions, show the problem to someone who knows for
certain.
Finally, a command's intended definition may not be best for editing
with. This is a very important sort of problem, but it is also a
matter of judgement. Also, it is easy to come to such a conclusion
out of ignorance of some of the existing features.
How to Report a Bug
-------------------
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 a fresh
Emacs just loaded, until the problem happens. Send the bug report to
bug-gnu-emacs@mit-prep.arpa
The most important principle in reporting a bug is to report FACTS,
not hypotheses or conditions. It is always easier to report the
facts, but people seem to prefer to strain to think up explanations
and report them instead. If the explanations are based on guesses
about how Emacs is implemented, they will be useless; we will have to
try to figure out what the facts must have been to lead to such
speculations. Sometimes this is impossible. But in any case, it is
unnecessary work for us.
For example, suppose that you type C-X C-F /glorp/baz/ugh<return>,
finding a file which (you know) happens to be rather large, and Emacs
prints out "I feel pretty today". The best way to report the bug is
with a sentence like the preceding one, because it gives all the facts
and nothing but the facts.
Do not assume that the problem is due to the size of the file and say
"When I read in a large file, Emacs prints out 'I feel pretty today'".
This is what we mean by "guessing explanations". The problem is just
as likely to be due to the fact that there is a "Z" in the filename.
If this is so, then when we got your report, we would try out the
problem with some "big file", probably with no "Z" in its name, and
not find anything wrong. There is no way in the world that we could
guess that we should try finding a file with a "Z" in its name.
Alternatively, the problem might be due to the fact that the file
starts with exactly 25 spaces. For this reason, you should make sure
that you don't change the file until we have looked at it. Suppose
the problem only occurs when you have typed the C-X C-A command
previously? This is why we ask you to give the exact sequence of
characters you typed since loading the Emacs.
You should not even say "find the file ..." instead of "C-X C-F"
unless you know that it makes no difference which file-finding command
is used. Similarly, rather than saying "if I have three characters on
the line", say "after I type <cr> A B C <cr> C-P", if that is the way
you entered the text. A journal file (see the function
"open-dribble-file") containing the commands you typed to reproduce
the bug is a very good form of report. For suspected display bugs, a
transcripts of the actual characters which Emacs is transmitting to
your terminal may be obtained by way of the "open-termscript"
function. (Note that these two functions only exist in more recent
emacs version.)
If you are not in Fundamental mode when the problem occurs, you should
say what mode you are in.
Be sure to say what version of Emacs and Unix are running. If you
don't know, type Meta-x emacs-version<return> and Emacs will print out
its version number.
If the bug occurred in a customized Emacs, or with several optional
libraries loaded, it is helpful to try to reproduce the bug in a more
standard Emacs with fewer libraries loaded. It is best if you can
make the problem happen in a completely standard Emacs with no
optional libraries. If the problem does NOT occur in a standard
Emacs, it is very important to report that fact, because otherwise we
will try to debug it in a standard Emacs, not find the problem, and
give up. If the problem does depend on an init file, then you should
make sure it is not a bug in the init file by complaining to the
person who wrote the file, first. He should check over his code, and
verify the definitions of the Emacs-lisp commands he is using. Then
if he verifies that the bug is in Emacs he should report it. We
cannot be responsible for maintaining users' init files; we might not
even be able to tell what they are supposed to do.
If you can tell us a way to cause the problem without reading in any
files, please do so. This makes it much easier to debug. If you do
need files, make sure you arrange for us to see their exact contents.
For example, it can often matter whether there are spaces at the ends of
lines, or a line separator after the last line in the buffer (nothing
ought to care whether the last line is terminated, but tell that to the
bugs).