]> git.eshelyaron.com Git - emacs.git/commitdiff
Minor wording change in ELisp manual
authorRichard Stallman <rms@gnu.org>
Sun, 27 Oct 2019 02:02:57 +0000 (22:02 -0400)
committerEli Zaretskii <eliz@gnu.org>
Fri, 1 Nov 2019 09:45:51 +0000 (11:45 +0200)
* doc/lispref/functions.texi (Advising Named Functions):
Improve and clarify wording of the advice to avoid advising
functions in released code.

doc/lispref/functions.texi

index eced3a244747579f4496a42d5a6daba72740cb4e..12112508b01c4818e151e3ea9066f6800479d9e6 100644 (file)
@@ -1811,9 +1811,15 @@ possible to do the same thing via a hook, that is preferable
 (@pxref{Hooks}).  If you simply want to change what a particular key
 does, it may be better to write a new command, and remap the old
 command's key bindings to the new one (@pxref{Remapping Commands}).
-In particular, Emacs's own source files should not put advice on
-functions in Emacs.  (There are currently a few exceptions to this
-convention, but we aim to correct them.)
+
+  If you are writing code for release, for others to use, try to avoid
+including advice in it.  If the function you want to advise has no
+hook to do the job, please talk with the Emacs developers about adding
+a suitable hook.  Especially, Emacs's own source files should not put
+advice on functions in Emacs.  (There are currently a few exceptions
+to this convention, but we aim to correct them.)  It is generally
+cleaner to create a new hook in @code{foo}, and make @code{bar} use
+the hook, than to have @code{bar} put advice in @code{foo}.
 
   Special forms (@pxref{Special Forms}) cannot be advised, however macros can
 be advised, in much the same way as functions.  Of course, this will not affect