Prev: Checklist Up: Bugs
Sending Patches for GNU Emacs
If you would like to write bug fixes or improvements for GNU Emacs,
that is very helpful. When you send your changes, please follow these
guidelines to make it easy for the maintainers to use them.
If you don't follow these guidelines, your information might still be
useful, but using it will take extra work. Maintaining GNU Emacs is a
lot of work in the best of circumstances, and we can't keep up unless
you do your best to help.
* Send an explanation with your changes of what problem they fix or
what improvement they bring about. For a bug fix, just include a
copy of the bug report, and explain why the change fixes the bug.
(Referring to a bug report is not as good as including it, because
then we will have to look it up, and we have probably already
deleted it if we've already fixed the bug.)
* Always include a proper bug report for the problem you think you
have fixed. We need to convince ourselves that the change is
right before installing it. Even if it is correct, we might have
trouble understanding it if we don't have a way to reproduce the
* Include all the comments that are appropriate to help people
reading the source in the future understand why this change was
* Don't mix together changes made for different reasons. Send them
If you make two changes for separate reasons, then we might not
want to install them both. We might want to install just one. If
you send them all jumbled together in a single set of diffs, we
have to do extra work to disentangle them--to figure out which
parts of the change serve which purpose. If we don't have time
for this, we might have to ignore your changes entirely.
If you send each change as soon as you have written it, with its
own explanation, then the two changes never get tangled up, and we
can consider each one properly without any extra work to
* Send each change as soon as that change is finished. Sometimes
people think they are helping us by accumulating many changes to
send them all together. As explained above, this is absolutely
the worst thing you could do.
Since you should send each change separately, you might as well
send it right away. That gives us the option of installing it
immediately if it is important.
* Use `diff -c' to make your diffs. Diffs without context are hard
to install reliably. More than that, they are hard to study; we
must always study a patch to decide whether we want to install it.
Unidiff format is better than contextless diffs, but not as easy
to read as `-c' format.
If you have GNU diff, use `diff -cp', which shows the name of the
function that each change occurs in.
* Write the change log entries for your changes. This is both to
save us the extra work of writing them, and to help explain your
changes so we can understand them.
The purpose of the change log is to show people where to find what
was changed. So you need to be specific about what functions you
changed; in large functions, it's often helpful to indicate where
within the function the change was.
On the other hand, once you have shown people where to find the
change, you need not explain its purpose. Thus, if you add a new
function, all you need to say about it is that it is new. If you
feel that the purpose needs explaining, it probably does--but the
explanation will be much more useful if you put it in comments in
Please read the `ChangeLog' file to see what sorts of information
to put in, and to learn the style that we use. If you would like
your name to appear in the header line showing who made the
change, send us the header line.
* When you write the fix, keep in mind that we can't install a
change that would break other systems. Please think about what
effect your change will have if compiled on another type of system.
Sometimes people send fixes that *might* be an improvement in
general--but it is hard to be sure of this. It's hard to install
such changes because we have to study them very carefully. Of
course, a good explanation of the reasoning by which you concluded
the change was correct can help convince us.
The safest changes are changes to the configuration files for a
particular machine. These are safe because they can't create new
bugs on other machines.
Please help us keep up with the workload by designing the patch in
a form that is clearly safe to install.
automatically generated by info2www