Re: Finalizing 'inhibit-automatic-native-compilation'

[Richard Stallman <rms@gnu.org>]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Native compilation or no, I think that releasing a package A that puts
  > > advice on functions outside of A is asking to lose.

  > ??

  > That's the whole point of advice.

Not at all.  The point of advice is for _users_ to alter functions
in Emacs.  But code in Emacs should never do that.

If you want file A to modify the way file B operates, and these
are both parts of Emacs, the proper way to do it is for B to define a
hook variable, and document it.  Then A can put something on that
hook.

The reason for this is to avoid confusion that hampers debugging.
If B's behavior is altered through a hook, you will see in the code
for B that it calls a hook at a certain place.  That wil remind you
to check the hook variable's value to see if that is affecting behavior.

But if B's behavior has been altered through advice, nothing you
see will remind you to check whether B is advised.

The node Advising Named Functions in the Emacs Lisp Reference says:

      For these reasons, advice should be reserved for the cases where you
    cannot modify a function's behavior in any other way.  If it is
    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}).

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

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)