bug#61553: 29.0.60; Inconsistent use of dialog boxes by read-multiple-choice

[Robert Pluim]

>>>>> On Fri, 17 Feb 2023 14:31:06 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Augusto Stoffel <arstoffel@gmail.com>,  61553@debbugs.gnu.org
    >> Date: Fri, 17 Feb 2023 11:24:09 +0100
    >> 
    >> >>>>> On Thu, 16 Feb 2023 22:17:18 +0200, Eli Zaretskii <eliz@gnu.org> 
said:
    >> 
    >> >> 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.
    >> 
    Eli> I disagree that rmc.el should make that decision.  It isn't its call
    Eli> (pun intended).
    >> 
    >> If we do this then we need to modify the docstring of
    >> `read-multiple-choice', which explicitly defines the current
    >> behaviour:
    >> 
    >> When `use-dialog-box' is t (the default), and the command using this
    >> function was invoked via the mouse, this function pops up a GUI dialog
    >> to collect the user input, but only if Emacs is capable of using GUI
    >> dialogs.  Otherwise, the function will always use text-mode dialogs.
    >> 
    >> The return value is the matching entry from the CHOICES list.
    >> 
    >> If LONG-FORM, do a `completing-read' over the NAME elements in
    >> CHOICES instead.

    Eli> Where exactly is the above wrong?

Itʼs not wrong, it just could be clearer.

    Eli> The only problem I found in that function is that it evidently was
    Eli> never actually tested with GUI dialogs, because trying to do that
    Eli> revealed at least two (albeit minor) issues with what it did in that
    Eli> case.  Both of them are solved in the patch I proposed.

    >> Although perhaps we could clarify it:
    >> 
    >> If LONG-FORM, always do a `completing-read' over the NAME elements in
    >> CHOICES instead, regardless of the value of `use-dialog-box'.

    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.

Robert
--