Use of advice [was: Is it valid to call isearch-filter-predicate outside isearch?]

Use of advice [was: Is it valid to call isearch-filter-predicate outside isearch?]

[Drew Adams]

> >> 2. It feels against the interface. If advising this predicate is
> >>    expected, why not convert it into an abnormal hook?
> >
> > It's more flexible and expressive, as Drew already mentioned.  For
> > example, how the members of a hook are logically combined (`and'ed,
> > `or'ed) is fixed in a hook, but not when using advising.
> 
> Interesting.
> From Elisp Tips in the manual, I always felt that using advices is
> always frowned upon. And you are suggesting that they are the better way
> to go in these situations.
> I am wondering if this thing with modifying predicates should be
> documented somewhere and recommended approach.

This is a good point/question.

FWIW, IMO (so far) - and obviously I don't speak
for Emacs and I'm no expert on this:

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.

2. There's a difference between the old advice
   and the new one (nadvice).  Dunno how relevant
   it might be, here.  The capabilities,
   opaqueness, and fragility of the two aren't
   the same, I think.

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

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.

4. Yes, it might be good to (somehow) document the
   use of advice more/better, including tradeoffs
   involved.

   This won't be easy to do well, I expect.  Someone
   who knows nadvice well, like Stefan or Michael H,
   might need to get involved, to come up with
   accurate & useful guidance for us mere users. ;-)
   
   If done poorly the result might be worse than the
   current relative lack of such guidance.  Or not.
   We won't know till someone tries.

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

[Michael Heerdegen]

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.

RE: [External] : Re: Use of advice [was: Is it valid to call isearch-filter-predicate outside isearch?]

[Drew Adams]

> if you use named advices,
> debugging and analyzing can be simple.

Yes. Naming advice is pretty essential if you
want some flexibility - being able to add &
remove bits etc.

> In the Elisp sources, instead of modifying
> the function binding of a variable ... the
> bound function could maybe just be changed
> to handle all situations.  Then the code
> would not have to change the variable at all.

Not sure what you have in mind there.

In the application I spoke of, the value (of
`isearch-filter-predicate') gets advised.
And advised, and advised,..., accumulating
advice to tweak/refine the behavior.  And any
added advice can get also get removed.

A user does this interactively.  Any given state
of the variable can be saved and restored, so if
something (you or something else) changes the
variable value for some reason you can easily
get back to a previous state if you want.

This particular interactive use of advice isn't
about the Elisp sources using advice.  So I guess
it's not quite the same thing you're talking about.

> ... advised variables are more like hooks: you
> add and remove functions, but you don't set it.

Coming back to the example I referred to, yes,
that's why I used advice.  But with hooks you
have only the order of the hook functions to
fiddle with.  With advice you have greater
flexibility.

Wrt "you don't set it": You _can_ replace the
original effect completely, which is essentially
setting it.  (And both a variable setting and a
replacement advice can be reversed/restored,
with some foresight.)

Advice lets you do pretty much anything to the
behavior.  But again, yes, to be able to
add/subtract etc. easily you really want to
use _named_ advice.

> 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.

By "considered to be" I guess you mean
"intended" or "expected" to be.  I guess you're
talking about a variable that's expected to be
used a bit like a hook.

That's the case, BTW, for variables such as
`isearch-filter-predicate'.  (OK, it uses suffix
`-predicate' instead of `-function' or `-hook'.
But the idea's the same.)

> 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).

+1 to that.  I expect more needs to be done
wrt the debugger as well, to make what's
going on clearer.

Re: [External] : Re: Use of advice [was: Is it valid to call isearch-filter-predicate outside isearch?]

[Michael Heerdegen]

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

> In the application I spoke of, the value (of
> `isearch-filter-predicate') gets advised.
> And advised, and advised,..., accumulating
> advice to tweak/refine the behavior.  And any
> added advice can get also get removed.
>
> A user does this interactively.  Any given state
> of the variable can be saved and restored, so if
> something (you or something else) changes the
> variable value for some reason you can easily
> get back to a previous state if you want.
>
> This particular interactive use of advice isn't
> about the Elisp sources using advice.  So I guess
> it's not quite the same thing you're talking about.

Yes, I think in such situations it's ok to use advices.  It's not really
possible to avoid them.

> > ... advised variables are more like hooks: you
> > add and remove functions, but you don't set it.
>
> Coming back to the example I referred to, yes,
> that's why I used advice.  But with hooks you
> have only the order of the hook functions to
> fiddle with.  With advice you have greater
> flexibility.

Exactly.  Advising is only a bit less transparent for that reason.

> Wrt "you don't set it": You _can_ replace the
> original effect completely, which is essentially
> setting it.  (And both a variable setting and a
> replacement advice can be reversed/restored,
> with some foresight.)
>
> Advice lets you do pretty much anything to the
> behavior.  But again, yes, to be able to
> add/subtract etc. easily you really want to
> use _named_ advice.

If you speak of :override: yes... but these can also get effected by
other advices, and different :override advices of different depths
concur.  That's what I wanted to mention.

> > 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.
>
> By "considered to be" I guess you mean
> "intended" or "expected" to be.  I guess you're
> talking about a variable that's expected to be
> used a bit like a hook.
>
> That's the case, BTW, for variables such as
> `isearch-filter-predicate'.  (OK, it uses suffix
> `-predicate' instead of `-function' or `-hook'.
> But the idea's the same.)

Yes, we have a few.  But `-predicate' is irrelevant for naming - not all
such places will be predicate functions.  And you can't tell from the
name that the variable should be advised and not set.


Michael.

RE: [External] : Re: Use of advice [was: Is it valid to call isearch-filter-predicate outside isearch?]

[Drew Adams]

> > > 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.
> >
> > I guess you're talking about a variable that's
> > expected to be used a bit like a hook.
> >
> > That's the case, BTW, for variables such as
> > `isearch-filter-predicate'.  (OK, it uses suffix
> > `-predicate' instead of `-function' or `-hook'.
> > But the idea's the same.)
> 
> Yes, we have a few.  But `-predicate' is irrelevant
> for naming - not all such places will be predicate
> functions.  And you can't tell from the name that
> the variable should be advised and not set.

Are you talking about an advice name or the name
of a predicate-valued variable?

For the latter, we could adopt suffix `-predicate'
conventionally.  A predicate in Lisp is a Boolean
function.  (It's not just a Boolean value.)

However, just as with other functions, predicates
can have different signatures.  So that suffix
would correspond to an "abnormal" hook, i.e., one
whose value could accept args.
____

I'll also pointed out that predicates are
_particularly_ useful use cases for advice, as
the ways you can combine the advice include the
usual logical combinations (AND, OR, NOT).

IOW, knowing that the function being advised, as
well as the intended result of advising, are to
be _predicates_ means you can use such general
logical combinations as ways of advising them.

That's what my Isearch dynamic filtering code
does: it lets you combine predicates easily
(interactively) using AND, OR, and NOT, among
other possibilities.

And there are two versions of ORing and
complementing:

1. Just add a predicate, ORing/complementing
   the current predicate.

2. Replace the last-added predicate (advice)
   by its disjunction with a new predicate
   or by its complement.

https://www.emacswiki.org/emacs/DynamicIsearchFiltering#FilteringCommandsAvailableDuringSearch

Advising an arbitrary function doesn't allow such
combining possibilities.  But at least you still
have some other general operations: add advice,
remove advice, replace advice, list/show/describe
current advice, save current advised definition
(to reuse later), keep or not for subsequent
commands, reset to original predicate.

Re: [External] : Re: Use of advice [was: Is it valid to call isearch-filter-predicate outside isearch?]

[Michael Heerdegen]

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

> Are you talking about an advice name or the name
> of a predicate-valued variable?

Actually, about the names of function value'd variables that we want to
use or suggest for advising.

> I'll also pointed out that predicates are
> _particularly_ useful use cases for advice, as
> the ways you can combine the advice include the
> usual logical combinations (AND, OR, NOT).

Indeed.  Maybe a lot or most of the cases of function value'd
variables are predicate valued variables.


BTW, there is a case that is not so sexy: the case of variables that can
be bound to a function but also allow other values (like nil, t, a
string).  We also have these cases in our sources.  One must not install
advises for these.

Michael.

RE: [External] : Re: Use of advice [was: Is it valid to call isearch-filter-predicate outside isearch?]

[Ihor Radchenko]

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

>> 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).
>
> +1 to that.  I expect more needs to be done
> wrt the debugger as well, to make what's
> going on clearer.

I am not sure about the debugger.
IMHO, the current situation is not too different from how macro
expansion shows up in the debugger.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Ihor Radchenko]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> 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).

AFAIK, helpful.el does add this indication.
https://yhetil.org/emacs-devel/AM9PR09MB4977A7738F83C5C24EF5829196D59@AM9PR09MB4977.eurprd09.prod.outlook.com/

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

RE: [External] : Re: Use of advice [was: Is it valid to call isearch-filter-predicate outside isearch?]

[Drew Adams]

> > 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).
> 
> AFAIK, helpful.el does add this indication.

Isearch+ also provides it, on demand while
searching:

`C-z ?' ('isearchp-show-filters') echoes the
current suite of filter predicates (advice
and original, unadvised predicate).

IOW, _while you're using_ an advised function
you can show what the advice consists of.