* doc/lispref/tips.texi (Coding Conventions): Recommend cl-lib over cl.

This commit is contained in:
Glenn Morris 2012-10-21 19:18:58 -07:00
parent ef44695952
commit 5fb904b0e4
2 changed files with 14 additions and 7 deletions

View file

@ -1,3 +1,7 @@
2012-10-22 Glenn Morris <rgm@gnu.org>
* tips.texi (Coding Conventions): Recommend cl-lib over cl.
2012-10-15 Chong Yidong <cyd@gnu.org>
* macros.texi (Defining Macros): defmacro is now a macro.

View file

@ -120,15 +120,18 @@ library when needed. This way people who don't use those aspects of
your file do not need to load the extra library.
@item
Please don't require the @code{cl} package of Common Lisp extensions at
run time. Use of this package is optional, and it is not part of the
standard Emacs namespace. If your package loads @code{cl} at run time,
that could cause name clashes for users who don't use that package.
If you need Common Lisp extensions, use the @code{cl-lib} library
rather than the old @code{cl} library. The latter does not
use a clean namespace (i.e., its definitions do not
start with a @samp{cl-} prefix). If your package loads @code{cl} at
run time, that could cause name clashes for users who don't use that
package.
However, there is no problem with using the @code{cl} package at
compile time, with @code{(eval-when-compile (require 'cl))}. That's
There is no problem with using the @code{cl} package at @emph{compile}
time, with @code{(eval-when-compile (require 'cl))}. That's
sufficient for using the macros in the @code{cl} package, because the
compiler expands them before generating the byte-code.
compiler expands them before generating the byte-code. It is still
better to use the more modern @code{cl-lib} in this case, though.
@item
When defining a major mode, please follow the major mode