[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Finalizing 'inhibit-automatic-native-compilation'
From: |
Richard Stallman |
Subject: |
Re: Finalizing 'inhibit-automatic-native-compilation' |
Date: |
Wed, 01 Feb 2023 00:04:34 -0500 |
[[[ 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)
- Re: Finalizing 'inhibit-automatic-native-compilation',
Richard Stallman <=
- Re: Finalizing 'inhibit-automatic-native-compilation', Lynn Winebarger, 2023/02/04
- Re: Finalizing 'inhibit-automatic-native-compilation', Eli Zaretskii, 2023/02/04
- Re: Finalizing 'inhibit-automatic-native-compilation', Lynn Winebarger, 2023/02/04
- Re: Finalizing 'inhibit-automatic-native-compilation', Eli Zaretskii, 2023/02/05
- Re: Finalizing 'inhibit-automatic-native-compilation', Lynn Winebarger, 2023/02/05
- Re: Finalizing 'inhibit-automatic-native-compilation', Andrea Corallo, 2023/02/06
- Re: Finalizing 'inhibit-automatic-native-compilation', Andrea Corallo, 2023/02/06
- Re: Finalizing 'inhibit-automatic-native-compilation', Eli Zaretskii, 2023/02/06
- Re: Finalizing 'inhibit-automatic-native-compilation', Lynn Winebarger, 2023/02/06
- Re: Finalizing 'inhibit-automatic-native-compilation', Eli Zaretskii, 2023/02/06