4 Emacs is a collaborative project and we encourage contributions from
5 anyone and everyone. If you want to contribute in the way that will
6 help us most, we recommend (1) fixing reported bugs and (2)
7 implementing the feature ideas in etc/TODO. However, if you think of
8 new features to add, please suggest them too -- we might like your
9 idea. Porting to new platforms is also useful, when there is a new
10 platform, but that is not common nowadays.
12 For documentation on how to develop Emacs changes, refer to the Emacs
13 Manual and the Emacs Lisp Reference Manual (both included in the Emacs
14 distribution). The web pages in http://www.gnu.org/software/emacs
15 contain additional information.
17 You may also want to submit your change so that can be considered for
18 inclusion in a future version of Emacs (see below).
20 If you don't feel up to hacking Emacs, there are many other ways to
21 help. You can answer questions on the mailing lists, write
22 documentation, find and report bugs, contribute to the Emacs web
23 pages, or develop a package that works with Emacs.
25 Here are some style and legal conventions for contributors to Emacs:
30 Contributed code should follow the GNU Coding Standard.
31 If it doesn't, we'll need to find someone to fix the code
34 Emacs has certain additional style and coding conventions.
36 Ref: http://www.gnu.org/prep/standards_toc.html
37 Ref: Standards Info Manual
40 o Copyright Assignment
42 We can accept small changes without legal papers, and for
43 medium-size changes a copyright disclaimer is ok too. Toa
44 accept substantial contributions from you, we need a copyright
45 assignment form filled out and filed with the FSF.
47 Contact us at emacs-devel@gnu.org to obtain the relevant
51 o Getting the Source Code
53 The latest version of Emacs can be downloaded using CVS or
54 Arch from the Savannah web site. It is important to write
55 your patch based this version; if you start from an older
56 version, your patch may be outdated when you write it.
58 Ref: http://savannah.gnu.org/projects/emacs
63 Every patch must have several pieces of information before we
64 can properly evaluate it.
66 For bug fixes, a description of the bug and how your patch fixes
69 For new features, a description of the feature and your
72 A ChangeLog entry as plaintext (separate from the patch); see
73 the various ChangeLog files for format and content. Note that,
74 unlike some other projects, we do require ChangeLogs also for
75 documentation i.e. texinfo files.
77 Ref: Change Log Concepts node of the Standards Info Manual
79 The patch itself. If you are accessing the CVS repository use
80 "cvs update; cvs diff -cp"; else, use "diff -cp OLD NEW". If
81 your version of diff does not support these options, then get
82 the latest version of GNU diff.
84 We accept patches as plain text (preferred for the compilers
85 themselves), MIME attachments (preferred for the web pages), or
86 as uuencoded gzipped text.
88 When you have all these pieces, bundle them up in a mail message
89 and send it to emacs-pretest-bug@gnu.org or emacs-devel@gnu.org.
90 All subsequent discussion should also be sent to the mailing
94 o Please reread your patch before submitting it.
97 o If you send several unrelated changes together, we will
98 ask you to separate them so we can consider each of the changes
102 o Supplemental information for Emacs Developers:
104 Once you become a frequent contributor to Emacs, we can
105 consider giving you write access to the CVS repository.
107 Discussion about Emacs development takes place on
110 Think carefully about whether your change requires updating the
111 documentation. If it does, you can either do this yourself or
112 add an item to the NEWS file.
114 The best way to understand Emacs Internals is to read the code
115 but the nodes "Tips" and "GNU Emacs Internals" in the Appendix
116 of the Emacs Lisp Reference Manual may also help.
118 The file DEBUG describes how to debug Emacs bugs.
120 Avoid using `defadvice' or `eval-after-load' for Lisp
121 code to be included in Emacs.