From: Drew Adams <drew.adams@oracle.com>
To: Michael Heerdegen <michael_heerdegen@web.de>
Cc: Eli Zaretskii <eliz@gnu.org>,
"59559@debbugs.gnu.org" <59559@debbugs.gnu.org>
Subject: bug#59559: 28.1; `minibuffer-with-setup-hook' with :append
Date: Mon, 23 Jan 2023 16:38:53 +0000 [thread overview]
Message-ID: <SJ0PR10MB5488EA8EAA7D6A96D3CFE7E7F3C89@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <87bkmppchf.fsf@web.de>
> Drew, thanks for your elaborations.
You're welcome. Thanks for working on this.
> I don't have a strong opinion. I can follow your thoughts, but I'm also
> not really convinced that writing that all out in the docstring is
> necessary.
>
> So I would like to leave it up to you two to find a final agreement.
Eli has now decided - apparently it's "won't fix".
FWIW, I think this kind of interface is inherently
problematic (for the reasons I gave). It's not
similar to, say, `add-hook', where APPEND can be
an optional arg. (Nor is it like CL keyword args.)
No one has any trouble understanding that a macro
like `with-current-buffer' evals its first arg,
so no special need for the doc to point that out.
If this case were like that (and others, similar)
I wouldn't have filed the bug report.
It's the use by `minibuffer-with-setup-hook' of
the same arg with two forms, and with evaluation
not always of that arg but sometimes of just part
of it -- that's what makes it problematic for the
doc to just talk about FUN being a function. IMO
the doc does _need_ to talk about how the arg is
handled (evaluated).
FWIW, I would have just had two macros, instead
of fiddling with a special kind of arg:
1. `with-mbuf-setup-hook-add' (or
`with-mbuf-setup-hook-prepend')
2. `with-mbuf-setup-hook-append'
That also uses fewer chars:
(with-mbuf-setup-hook-append #'toto ...)
(minibuffer-with-setup-hook (:append #'toto) ...)
Even if "minibuffer" is spelled out it's shorter:
(with-minibuffer-setup-hook-append #'toto ...)
And starting with "with-" fits what we do with
other, similar macros.
next prev parent reply other threads:[~2023-01-23 16:38 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-25 2:55 bug#59559: 28.1; `minibuffer-with-setup-hook' with :append Drew Adams
2022-11-25 3:07 ` Drew Adams
2023-01-10 17:37 ` Michael Heerdegen
2023-01-10 18:37 ` Drew Adams
2023-01-10 19:34 ` Michael Heerdegen
2023-01-10 19:53 ` Michael Heerdegen
2023-01-10 20:56 ` Drew Adams
2023-01-10 20:45 ` Drew Adams
2023-01-21 14:36 ` Michael Heerdegen
2023-01-21 15:35 ` Eli Zaretskii
2023-01-21 16:07 ` Michael Heerdegen
2023-01-21 18:43 ` Eli Zaretskii
2023-01-21 18:57 ` Drew Adams
2023-01-21 19:26 ` Eli Zaretskii
2023-01-21 18:51 ` Drew Adams
2023-01-21 19:23 ` Eli Zaretskii
2023-01-21 20:57 ` Drew Adams
2023-01-21 18:41 ` Drew Adams
2023-01-21 19:29 ` Eli Zaretskii
2023-01-21 20:27 ` Michael Heerdegen
2023-01-22 5:58 ` Eli Zaretskii
2023-01-22 22:10 ` Drew Adams
2023-01-22 22:19 ` Drew Adams
2023-01-23 0:15 ` Michael Heerdegen
2023-01-23 3:14 ` Drew Adams
2023-01-23 3:21 ` Drew Adams
2023-01-23 14:11 ` Michael Heerdegen
2023-01-23 16:38 ` Drew Adams [this message]
2023-01-23 12:15 ` Eli Zaretskii
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=SJ0PR10MB5488EA8EAA7D6A96D3CFE7E7F3C89@SJ0PR10MB5488.namprd10.prod.outlook.com \
--to=drew.adams@oracle.com \
--cc=59559@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=michael_heerdegen@web.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).