From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: bug-cc-mode@gnu.org, acm@muc.de, emacs-devel@gnu.org, raman@google.com
Subject: Re: Last use of defadvice in Emacs
Date: Fri, 08 Apr 2022 09:00:34 +0300 [thread overview]
Message-ID: <83fsmoazct.fsf@gnu.org> (raw)
In-Reply-To: <jwvtub4ps3j.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Thu, 07 Apr 2022 17:59:41 -0400)
> 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.
next prev parent reply other threads:[~2022-04-08 6:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-04 19:49 Last use of defadvice in Emacs Stefan Monnier
2022-04-04 20:08 ` T.V Raman
2022-04-04 20:38 ` Stefan Monnier via CC-Mode-help
2022-04-04 20:48 ` T.V Raman
2022-04-05 4:28 ` Richard Stallman
2022-04-06 18:52 ` Alan Mackenzie
2022-04-06 21:08 ` Stefan Monnier via CC-Mode-help
2022-04-07 1:51 ` T.V Raman
2022-04-07 2:49 ` Stefan Monnier via CC-Mode-help
2022-04-07 6:14 ` Eli Zaretskii
2022-04-07 21:59 ` Stefan Monnier via CC-Mode-help
2022-04-08 1:49 ` T.V Raman
2022-04-08 2:34 ` Stefan Monnier via CC-Mode-help
2022-04-08 14:21 ` T.V Raman
2022-04-08 6:00 ` Eli Zaretskii [this message]
2022-04-07 18:18 ` Alan Mackenzie
2022-04-07 18:37 ` Stefan Monnier
2022-04-08 17:10 ` Alan Mackenzie
2022-04-08 17:39 ` Stefan Monnier via CC-Mode-help
2022-04-08 18:06 ` Alan Mackenzie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83fsmoazct.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=acm@muc.de \
--cc=bug-cc-mode@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=raman@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).