From: Drew Adams <drew.adams@oracle.com>
To: Alan Mackenzie <acm@muc.de>
Cc: 33601@debbugs.gnu.org
Subject: bug#33601: 26; Add macro `with-hook-added'
Date: Tue, 4 Dec 2018 13:22:41 -0800 (PST) [thread overview]
Message-ID: <af5ddf3e-5b54-4173-be48-a68da743d989@default> (raw)
In-Reply-To: <20181204201048.GA13646@ACM>
> > > 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.
>
> > 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.
If there's an unwritten rule that `with-*' macros
preserve and restore everything then clearly the
macro I proposed was not a `with-*' macro. Another
name for it would be fine, if that's the rule. ;-)
> > 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?
The kind of thing I showed (with two examples).
Yes, I would use them where I either know that the
function is not on the hook already or I don't
care - cases where I would want it removed at the
end in any case.
And yes, given your question, the doc of such a
macro would need to make clear that it always
removes FUNCTION from the hook afterward.
> > 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?
All of the behaviors are useful. If you meant to ask
whether it is useful to have 8 individual macros, then
my answer is probably not.
> > 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.
I really have no problem with what you requested:
not removing FUNCTION at the end if it was present
beforehand.
However, now you've gone beyond that to suggest
that we should restore the original hook value:
"preserve the hook".
Should it preserve the hook? Maybe, maybe not.
How strict is your unwritten `with-*' rule? Does
it apply only to undoing the particular change _it_
makes, or does it also undo changes that might be
made by the BODY? In this case, the BODY might
itself make changes to the hook.
If I had to choose only one macro, it would
probably be a general one. I guess it would, as
you first requested, remove FUNCTION only if it
was not already present. And it would accept
args for APPEND and LOCAL. But it would not
restore the original hook value.
Whether it should require args APPEND and LOCAL
or it should instead make you wrap body sexps in
a progn is another choice. Dunno which I'd prefer,
but probably the former (probably less error prone).
Other ideas are welcome. What is your preference
(besides always restoring the original hook value)?
next prev parent reply other threads:[~2018-12-04 21:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <<mailman.5097.1543862895.1284.bug-gnu-emacs@gnu.org>
[not found] ` <<20181204184614.2049.qmail@mail.muc.de>
2018-12-04 19:18 ` bug#33601: 26; Add macro `with-hook-added' Drew Adams
2018-12-04 20:10 ` Alan Mackenzie
2018-12-04 21:22 ` Drew Adams [this message]
2018-12-03 18:47 Drew Adams
2018-12-03 19:01 ` Glenn Morris
2018-12-03 20:58 ` Drew Adams
2018-12-03 19:03 ` Drew Adams
2018-12-03 22:37 ` Phil Sainty
2018-12-03 22:50 ` Drew Adams
2018-12-03 23:13 ` Phil Sainty
2018-12-03 23:51 ` Drew Adams
[not found] ` <mailman.5097.1543862895.1284.bug-gnu-emacs@gnu.org>
2018-12-04 18:46 ` Alan Mackenzie
2022-02-12 8:46 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=af5ddf3e-5b54-4173-be48-a68da743d989@default \
--to=drew.adams@oracle.com \
--cc=33601@debbugs.gnu.org \
--cc=acm@muc.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).