comparison lispref/tips.texi @ 71036:2a973dfbccc2

(Coding Conventions): Better explain reasons not to advise other packages or use `eval-after-load'.

71035:3574bac9e172

      'point-at-bol
    'line-beginning-position))
@end example

@item
Redefining (or advising) an Emacs primitive is discouraged.  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.

@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
@code{eval-after-load}, and thus makes it harder to maintain the two
packages independently.

@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

71036:2a973dfbccc2

      'point-at-bol
    'line-beginning-position))
@end example

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

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