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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#61553: closed (29.0.60; Inconsistent use of dialog boxes by
 read-multiple-choice)
Date: Sun, 19 Feb 2023 09:33:01 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sun, 19 Feb 2023 11:32:26 +0200
with message-id <834jrixaol.fsf <at> gnu.org>
and subject line Re: bug#61553: 29.0.60; Inconsistent use of dialog boxes by read-multiple-choice
has caused the debbugs.gnu.org bug report #61553,
regarding 29.0.60; Inconsistent use of dialog boxes by read-multiple-choice
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
61553: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61553
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.60; Inconsistent use of dialog boxes by read-multiple-choice
Date: Thu, 16 Feb 2023 17:19:30 +0100

In the scratch buffer of emacs -Q, type

    (read-multiple-choice "Question" '((?y "yes") (?n "no")))

then click, on the menu bar, "Lisp-Interaction -> Evaluate and Print".
As expected, I see a dialog box.

Now repeat the same using the long-form style:

    (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.

As a more concrete example, when clicking the "File -> Close" menu item
in a modified buffer, I would expect a to always get a dialog box for
the "buffer modified, kill anyway?" question.  (assuming of course
use-dialog-box is t).  Currently, one gets a minibuffer query by
default.  This change from mouse interaction to keyboard interaction
seems unexpected to me.

[Message part 3 (message/rfc822, inline)]

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.