comparison lispref/tips.texi @ 71642:fa9d190c602e

(Coding Conventions): Cleanup last change.

71641:6edfaf0b0ec6

@item
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 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.

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 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
standard Emacs, prominent comments at the beginning of the file should
say which functions are replaced, and how the behavior of the

71642:fa9d190c602e

@item
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 problem
for debugging, because the 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.

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 program is unclean,
because it modifies the behavior of another Lisp file in a way that's
not visible in that file.  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
standard Emacs, prominent comments at the beginning of the file should
say which functions are replaced, and how the behavior of the