[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last use of defadvice in Emacs
From: |
Eli Zaretskii |
Subject: |
Re: Last use of defadvice in Emacs |
Date: |
Fri, 08 Apr 2022 09:00:34 +0300 |
> 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.
- Re: Last use of defadvice in Emacs, (continued)
- Re: Last use of defadvice in Emacs, Richard Stallman, 2022/04/05
- Re: Last use of defadvice in Emacs, Alan Mackenzie, 2022/04/06
- Re: Last use of defadvice in Emacs, Stefan Monnier, 2022/04/06
- Re: Last use of defadvice in Emacs, T.V Raman, 2022/04/06
- Re: Last use of defadvice in Emacs, Stefan Monnier, 2022/04/06
- Re: Last use of defadvice in Emacs, Eli Zaretskii, 2022/04/07
- Re: Last use of defadvice in Emacs, Stefan Monnier, 2022/04/07
- Re: Last use of defadvice in Emacs, T.V Raman, 2022/04/07
- Re: Last use of defadvice in Emacs, Stefan Monnier, 2022/04/07
- Re: Last use of defadvice in Emacs, T.V Raman, 2022/04/08
- Re: Last use of defadvice in Emacs,
Eli Zaretskii <=
- Re: Last use of defadvice in Emacs, Alan Mackenzie, 2022/04/07
- Re: Last use of defadvice in Emacs, Stefan Monnier, 2022/04/07
- Re: Last use of defadvice in Emacs, Alan Mackenzie, 2022/04/08
- Re: Last use of defadvice in Emacs, Stefan Monnier, 2022/04/08
- Re: Last use of defadvice in Emacs, Alan Mackenzie, 2022/04/08