4 Emacs is a collaborative project and one which wants to encourage new
5 development. You may wish to fix Emacs bugs, improve testing, port
6 Emacs to a new platform, update documentation, add new Emacs features,
7 and the like. To help with this, there is a lot of documentation
8 available. In addition to the user guide and Lisp Reference Manual in
9 the Emacs distribution, the Emacs web pages also contain much
12 You may also want to submit your change so that can be considered for
13 inclusion in a future version of Emacs (see below).
15 If you don't feel up to hacking Emacs, there are still plenty of ways to
16 help! You can answer questions on the mailing lists, write
17 documentation, find bugs, create a Emacs related website (contribute to
18 the official Emacs web site), or create a Emacs related software
19 package. We welcome all of the above and feel free to ask on the Emacs
20 mailing lists if you are looking for feedback or for people to review a
23 Ref: http://www.gnu.org/software/emacs/
25 Finally, there are certain legal requirements and style issues which
26 all contributors need to be aware of:
31 All contributions must conform to the GNU Coding Standard.
32 Submissions which do not conform to the standards will be
33 returned with a request to reformat the changes.
35 Emacs has certain additional coding requirements.
37 Ref: http://www.gnu.org/prep/standards_toc.html
38 Ref: Standards Info Manual
41 o Copyright Assignment
43 Before we can accept code contributions from you, we need a
44 copyright assignment form filled out and filed with the FSF.
46 Contact us via the Emacs mailing list to obtain the relevant
49 Small changes can be accepted without a copyright assignment
53 o Getting the Source Code
55 The latest version of Emacs can be downloaded using CVS or Arch
56 from the Savannah web site. It is important that you submit
57 your patch using this version, as any bug in a released version
58 of Emacs may already be fixed. It also makes it easier for
59 others to test your patch.
61 Ref: http://savannah.gnu.org/projects/emacs
66 Every patch must have several pieces of information before we
67 can properly evaluate it.
69 For bug fixes, a description of the bug and how your patch fixes
72 For new features, a description of the feature and your
75 A ChangeLog entry as plaintext (separate from the patch); see
76 the various ChangeLog files for format and content. Note that,
77 unlike some other projects, we do require ChangeLogs also for
78 documentation i.e. texinfo files.
80 Ref: Change Log Concepts node of the Standards Info Manual
82 The patch itself. If you are accessing the CVS repository use
83 "cvs update; cvs diff -cp"; else, use "diff -cp OLD NEW". If
84 your version of diff does not support these options, then get
85 the latest version of GNU diff.
87 We accept patches as plain text (preferred for the compilers
88 themselves), MIME attachments (preferred for the web pages), or
89 as uuencoded gzipped text.
91 When you have all these pieces, bundle them up in a mail message
92 and send it to emacs-pretest-bug@gnu.org or emacs-devel@gnu.org.
93 All subsequent discussion should also be sent to the mailing
97 o Please read your patch before submitting it.
99 A patch containing several unrelated changes reformats will be
100 returned with a request to send them separately.
103 o Supplemental information for Emacs Developers:
105 If you wish to contribute to Emacs on a regular basis then you
106 may be given write access to the CVS repository.
108 Discussion about Emacs development takes place on
111 Think carefully about whether your change requires updating the
112 documentation. If it does, you can either do this yourself or
113 add an item to the NEWS file.
115 The best way to understand Emacs Internals is to read the code
116 but the nodes "Tips" and "GNU Emacs Internals" in the Appendix
117 of the Emacs Lisp Reference Manual may also help.
119 The file DEBUG describes how to debug Emacs.
121 Avoid using `defadvice' or `eval-after-load' for lisp
122 code to be included in Emacs.