Re: Last use of defadvice in Emacs

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: raman@google.com,  acm@muc.de,  bug-cc-mode@gnu.org,  emacs-devel@gnu.org
> Date: Thu, 07 Apr 2022 17:59:41 -0400
> 
> > It would be nice if these issues (perhaps in less academic shape and
> > in more practical terms) could be added to the ELisp manual,
> 
> Not sure what "more practical terms" would look like.

Something that makes it clear why using defadvice with lexical-binding
will cause trouble: an explanation with one or two examples.

> BTW, in https://emacs.stackexchange.com/questions/3079/#3102
> I mention a few other reasons, such as:
> 
>     • Design simplicity: defadvice has various notions that are
>     generally difficult to understand precisely and/or rarely used.
>     E.g. the difference between "enabling" and "activating" advices.
>     Or the meaning of "pre" and/or "compiled".  There are also quirks in
>     the handling of `ad-do-it`, such as the fact that it looks like
>     a variable-reference rather than a call, or the fact that you need
>     to (setq ad-return-value ...) explicitly rather than simply
>     returning the value.
> 
>     • Defadvice suffers from various problems w.r.t macroexpansion and
>     compilation: the body of an advice is not exposed as "code" (which
>     the compiler and macroexpander see) but as "data" which is later on
>     combined to make up an expression.  So macroexpansion happens late
>     (which can causes surprises if you use things like
>     `(eval-when-compile (require 'foo))`) and lexical-scoping is hard to
>     preserve correctly.
> 
> E.g. regarding the first point, `ad-activate` or `ad-deactivate` are
> arguably misdesigns since they have a global effect (they affect all
> pieces of advice applied to a given function) and most uses of them are
> latent bugs.

This, too, is important to know, IMO.

> This said, I don't know how important it is to document those
> advantages

Well, I obviously think it is, which is why I asked to do that,
please.

> To me the main benefit is that `advice-add` is simpler both in
> implementation and in API (no need to learn about `add-(de)activate`,
> `ad-(g|s)et-arg(s)`, `ad-do-it`, `ad-(en|dis)able-advice`, the
> differences between "adding", "enabling", and "activating", the
> occasional need to figure how and when to compile the code, ...).

Perhaps, this should also be mentioned in the manual.

Thanks.