--- Begin Message ---
|
Subject: |
29.0.60; Inconsistent use of dialog boxes by read-multiple-choice |
|
Date: |
Thu, 16 Feb 2023 17:19:30 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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.
--- End Message ---
--- Begin Message ---
|
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@debbugs.gnu.org
> Date: Thu, 16 Feb 2023 22:17:18 +0200
> From: Eli Zaretskii <eliz@gnu.org>
>
> > From: Augusto Stoffel <arstoffel@gmail.com>
> > Cc: 61553@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@gmail.com>
> Cc: arstoffel@gmail.com, 61553@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.
--- End Message ---