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: Augusto Stoffel <arstoffel <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61553 <at> debbugs.gnu.org
Subject: bug#61553: 29.0.60; Inconsistent use of dialog boxes by read-multiple-choice
Date: Thu, 16 Feb 2023 19:36:36 +0100

On Thu, 16 Feb 2023 at 19:59, Eli Zaretskii wrote:

>> From: Augusto Stoffel <arstoffel <at> gmail.com>
>> 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.
>
> 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?

The purpose of long-form is to protect the user from doing something
dangerous by accidentally pressing a key.  I don't think a mouse
equivalent for that exists or is needed.

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.

Previous Next

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