emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Use of advice [was: Is it valid to call isearch-filter-predicate o


From: Michael Heerdegen
Subject: Re: Use of advice [was: Is it valid to call isearch-filter-predicate outside isearch?]
Date: Wed, 07 Jun 2023 01:36:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Drew Adams <drew.adams@oracle.com> writes:

> 1. I think the guideline is (has been) for Emacs
>    code (i.e., what GNU Emacs delivers) to avoid
>    use of advice in favor of hooks etc.
>
>    It may also be a useful guideline for users,
>    but I think it's more for Emacs developers.
>
>    The reasons given for the avoidance include
>    that the use of advice is opaque/complicated
>    - it can make things harder for users (or for
>    other code) to see and analyze what's going
>    on (e.g. in a debugger).
>
>    This is an important consideration.

It totally depends on the case.  But also a `setq' can make it hard to
see and analyze what is going on.  OTOH, if you use named advices,
debugging and analyzing can be simple.

About the guideline: If we do need to ask the question whether we should
prefer advising or a hook or `setq' calls a more general question has to
be answered first: if the current design is appropriate at all.  In the
Elisp sources, instead of modifying the function binding of a variable
one has to consider that the bound function could maybe just be changed
to handle all situations.  Then the code would not have to change the
variable at all.

Then a question is how likely it is that different programs
(Emacs, third-party packages, plus the user's code) might want to modify
the behavior of a function value'd variable at the same time.  If it is
likely, Emacs should probably avoid setting the variable in its sources.

>    The general guideline to avoid use of advice
>    was established when the old advice was used.
>    Maybe it needs some nuance/seasoning now (?).

At least: since the new mechanism can modify places (variables) as well
as functions, the old reasoning cannot be applied 1:1.  For variables
advising can be better than `setq' in some situations.

> 3. #1 doesn't take away from the fact that advice
>    (particularly nadvice) also offers additional
>    flexibility/power.  A hook or a function-valued
>    variable doesn't offer the same things.  IOW,
>    there are upsides as well as downsides to using
>    advice.
>
>    But I think it's still generally true that IF
>    you can do XYZ just as well without using advice,
>    THEN do so.  What's good is to understand the
>    tradeoffs.

The "if you can indeed do without" can be misleading, though.  One has
to keep in mind that third party code may need to interact with the code
one writes.  So simply asking "if I can do without" is too simple.

Something we have to consider also is that advising and setting (with
`setq' or `setq-local') don't behave symmetrically: if only one place in
the code uses `setq' on a variable all advices of that function value
are nullified there.  So, it's better to not change the value with
`setq'.  In this perspective advised variables are more like hooks: you
add and remove functions, but you don't set it.

Dunno if it would be worth it that variables which are considered to be
modified by advising should have a special suffix (like "-hook" for
hooks).  Or maybe we already more or less have it: "...-function".
`setq'ing such variables in the Emacs sources is probably not user
friendly.

Anyway, I think we (at least I) still learn about the consequences of
having this tool.  The "see what is going on" part would maybe be
facilitated if the *Help* pages would show a combined overview showing
which types of advices are applied in which order and at which depth
around an advised function (at least in not trivial cases).


Michael.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]