GNU bug report logs - #33601
26; Add macro `with-hook-added'

Previous Next

Full log

View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 33601 <at> debbugs.gnu.org
Subject: bug#33601: 26; Add macro `with-hook-added'
Date: Tue, 4 Dec 2018 20:10:48 +0000

Hello, Drew.

On Tue, Dec 04, 2018 at 11:18:29 -0800, Drew Adams wrote:
> > > Enhancement request: Please consider adding a macro such as this, to
> > > facilitate temporary use of a hook function.

> > > (defmacro with-hook-added (hook function &rest body)
> > >   "Evaluate forms in BODY with FUNCTION added to HOOK, then remove FUNCTION."
> > >   (declare (indent 1) (debug t))
> > >   `(unwind-protect (progn (add-hook ',hook ',function) ,@body)
> > >      (remove-hook ',hook ',function)))

> > Just a big point: you need to test whether FUNCTION is already on HOOK
> > at the start, and if so, not remove it at the end.

> Hi Alan,

> A big point?  Need to?

I think so, yes.  The essence of the `with-...' macros is that they
temporarily change something, then evaluate ,@body, and at the end, the
something is restored to what it was.

If with-hook-added didn't preserve the hook, it would be an anomaly, an
outlier, and quite possibly a PITA.

> That wasn't the behavior I had in mind for this, but it's
> another possibility.  I intended to provide only for the
> behavior of always removing at the end.

Why?  What's the use case?

> There are in fact several different possibilities for such
> a macro.  We could provide also for `add-hook' args APPEND
> and LOCAL.  I left that out as well.

> Choices:

> 1. Provide a single macro for all such possibilities, with
> 3 (mandatory) args for APPEND, LOCAL and whether to remove
> FUNCTION at the end if it was already present at the outset.

> 2. Provide multiple macros, each specific for a given case.

> #2 would mean 8 macros, to cover all the combinations
> (nil or t for each of the 3 args).

How many of these would actually be of any use?

> Another possibility would be to accept a single arg for
> the BODY code, instead of that being a &rest parameter,
> and so be able to provide those 3 behavior-specifying
> args as optional.  In that case, we'd want to decide on
> the best order among those args, e.g., based on which we
> expect to be used most often.

> I'm not sure what the right approach is.  I think the
> most common use case would be the one I wrote up (but
> I don't know that):

> . Always remove FUNCTION at the end
> . Prepend, not append.
> . Global, not local.

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.