GNU bug report logs -
#61553
29.0.60; Inconsistent use of dialog boxes by read-multiple-choice
Previous Next
Reported by: Augusto Stoffel <arstoffel <at> gmail.com>
Date: Thu, 16 Feb 2023 16:20:01 UTC
Severity: normal
Found in version 29.0.60
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#61553: 29.0.60; Inconsistent use of dialog boxes by read-multiple-choice
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 61553 <at> debbugs.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)]
> 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.
[Message part 3 (message/rfc822, inline)]
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.
This bug report was last modified 2 years and 88 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.