[Top][All Lists]

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

RE: 1) (elisp) `Advising Named Functions', 2) search filtering example

From: Drew Adams
Subject: RE: 1) (elisp) `Advising Named Functions', 2) search filtering example
Date: Mon, 17 Oct 2016 11:41:56 -0700 (PDT)

> >> If you do this, then you will break the callers, which expect the
> >> value of this variable to be a single function.
> >
> > Tell that to the doc string for `add-hook', which has said what it
> > says in this regard for a very long time.
> There is no contradiction between the two.  `add-hook's doc talks about
> the case where a "multiple-function hook" has a value which happens to
> be a single function (which is an acceptable value for those hooks, for
> historical reasons).

That's one interpretation.  There is no mention of the fact that
the hook it is talking about is necessarily a "multiple-function
hook" that happens to have a single function as value.

> Whereas we're here talking about "single-function hooks", i.e. variables
> which should only ever hold a single function and not a list of functions.
> You can use (add-hook <hook> <function>) on them, just like you can use
> (setq <hook> 5) on them.  That doesn't mean that it's correct to do so.

If you say so.  Who decided it is incorrect, and why?  As I noted,
previously it was not a no-no to use `add-hook' on such a hook,
and `add-hook' was specifically designed to handle the case of a
single function (whether "'multiple-function hook' that happens
to have a single function as value" or "single-function hook").

And unlike what you just said (you can but it is not correct to
do so - or is it just not necessarily correct?), the doc now says:

 "‘add-hook’ cannot be used to modify such a _single function
  hook_, and you have to use ‘add-function’ instead (*note
  Advising Functions::)."

I wonder who added that sentence. ;-)

reply via email to

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