@c -*-texinfo-*-
@c This is part of the XEmacs Lisp Reference Manual.
-@c Copyright (C) 1990, 1991, 1992, 1993 Free Software Foundation, Inc.
+@c Copyright (C) 1990, 1991, 1992, 1993 Free Software Foundation, Inc.
@c See the file lispref.texi for copying conditions.
@setfilename ../../info/tips.info
@node Tips, Building XEmacs and Object Allocation, MULE, Top
@item
Redefining an Emacs primitive is an even worse idea.
-It may do the right thing for a particular program, but
+It may do the right thing for a particular program, but
there is no telling what other programs might break as a result.
@item
coherent if all libraries use the same conventions.
@item
+Use names starting with a space for temporary buffers (@pxref{Buffer
+Names}), or at least call @code{buffer-disable-undo} on them. Otherwise
+they may stay referenced by internal undo variable(s) after getting
+killed. If this happens before dumping (@pxref{Building XEmacs}), this
+may cause fatal error when portable dumper is used.
+
+@item
Indent each function with @kbd{C-M-q} (@code{indent-sexp}) using the
default indentation parameters.
search functions can be used.
@item
-Certain built-in functions are handled specially in byte-compiled code,
+Certain built-in functions are handled specially in byte-compiled code,
avoiding the need for an ordinary function call. It is a good idea to
use these functions rather than alternatives. To see whether a function
is handled specially by the compiler, examine its @code{byte-compile}
@item
Format the documentation string so that it fits in an Emacs window on an
80-column screen. It is a good idea for most lines to be no wider than
-60 characters. The first line can be wider if necessary to fit the
+60 characters. The first line can be wider if necessary to fit the
information that ought to be there.
However, rather than simply filling the entire documentation string, you
can make it much more readable by choosing line breaks with care.
Use blank lines between topics if the documentation string is long.
-
+
@item
@strong{Do not} indent subsequent lines of a documentation string so
that the text is lined up in the source code with the text of the first
@end group
@end smallexample
-Every function that has no documentation string (because it is use only
+Every function that has no documentation string (because it is used only
internally within the package it belongs to), should have instead a
two-semicolon comment right before the function, explaining what the
function does and how to call it properly. Explain precisely what each
(@code{indent-for-comment}) and @key{TAB} (@code{lisp-indent-line})
automatically indent comments according to these conventions,
depending on the number of semicolons. @xref{Comments,,
-Manipulating Comments, emacs, The XEmacs Reference Manual}.
+Manipulating Comments, xemacs, The XEmacs User's Manual}.
@node Library Headers
@section Conventional Headers for XEmacs Libraries