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.