[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Emacs-diffs] Changes to emacs/lispref/tips.texi
From: |
Richard M. Stallman |
Subject: |
[Emacs-diffs] Changes to emacs/lispref/tips.texi |
Date: |
Mon, 29 May 2006 00:18:44 +0000 |
Index: emacs/lispref/tips.texi
diff -u emacs/lispref/tips.texi:1.79 emacs/lispref/tips.texi:1.80
--- emacs/lispref/tips.texi:1.79 Fri May 26 19:32:02 2006
+++ emacs/lispref/tips.texi Mon May 29 00:18:44 2006
@@ -174,19 +174,28 @@
@end example
@item
-Redefining (or advising) an Emacs primitive is discouraged. It may do
+Redefining (or advising) an Emacs primitive is a bad idea. It may do
the right thing for a particular program, but there is no telling what
-other programs might break as a result. In any case, it is a
-maintenance burden because the two packages become highly dependent on
-each other.
+other programs might break as a result. In any case, it is a problem
+for debugging, because the two advised function doesn't do what its
+source code says it does. If the programmer investigating the problem
+is unaware that there is advice on the function, the experience can be
+very frustrating.
+
+We hope to remove all the places in Emacs that advise primitives.
+In the mean time, please don't add any more.
+
address@hidden
+It is likewise a bad idea for one Lisp package to advise a function
+in another Lisp package.
@item
Likewise, avoid using @code{eval-after-load} (@pxref{Hooks for
Loading}) in libraries and packages. This feature is meant for
-personal customizations; using it in a Lisp package increases the
-coupling between it and the package mentioned in
address@hidden, and thus makes it harder to maintain the two
-packages independently.
+personal customizations; using it in a Lisp program is unclean because
+it modifies the behavior of another Lisp file in an invisible way.
+This is an obstacle for debugging, much like advising a function in
+the other package.
@item
If a file does replace any of the functions or library programs of