GNU bug report logs - #61553
29.0.60; Inconsistent use of dialog boxes by read-multiple-choice

Previous Next

Full log

Message #28 received at 61553-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: arstoffel <at> gmail.com, Robert Pluim <rpluim <at> gmail.com>
Cc: 61553-done <at> debbugs.gnu.org
Subject: Re: bug#61553: 29.0.60;
 Inconsistent use of dialog boxes by read-multiple-choice
Date: Sun, 19 Feb 2023 11:32:26 +0200

> Cc: 61553 <at> debbugs.gnu.org
> Date: Thu, 16 Feb 2023 22:17:18 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Augusto Stoffel <arstoffel <at> gmail.com>
> > Cc: 61553 <at> debbugs.gnu.org
> > Date: Thu, 16 Feb 2023 19:36:36 +0100
> > 
> > On Thu, 16 Feb 2023 at 19:59, Eli Zaretskii wrote:
> > 
> > >>     (read-multiple-choice "Question" '((?y "yes") (?n "no")) nil nil t)
> > >> 
> > >> Then I get a minibuffer query, but I would expect a dialog box in the
> > >> case as well.
> > >
> > > The long-form call does a completing-read, and we don't support that
> > > via GUI dialogs (how could we?).
> > 
> > Of course.  The point is what takes precedence: the decision to prefer a
> > dialog over keyboard input, or the decision to do a completing-read
> > instead of reading a single char?
> 
> I don't think the function itself can make that decision.  Only the
> caller knows what's right for the context.
> 
> > The purpose of long-form is to protect the user from doing something
> > dangerous by accidentally pressing a key.
> 
> That's only one possible cause of using the long form.  There could be
> others.
> 
> > So instead of adding a special case for kill-buffer, I would rather
> > modify the behavior of RMC to just ignore the long-form argument if
> > (use-dialog-box-p) returns t.  Apart from that, your patch seems fine.
> 
> I disagree that rmc.el should make that decision.  It isn't its call
> (pun intended).

No further comments, so I've now installed the proposed change on the
emacs-29 branch, and I'm closing this bug.

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: arstoffel <at> gmail.com,  61553 <at> debbugs.gnu.org
> Date: Fri, 17 Feb 2023 13:42:35 +0100
> 
>     Eli> Oh, you assume that the reader will not understand that
>     Eli> completing-read cannot possibly use GUI dialogs?  I'm okay with saying
>     Eli> that explicitly, although someone who uses these APIs must already
>     Eli> realize that.
> 
> I had to read it carefully to realize that the 'instead' referred to
> the use of dialogs.

I've made this aspect more explicit in the doc string, thanks.

Previous Next

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