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

[Eli Zaretskii]

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

Where exactly is the above wrong?

The only problem I found in that function is that it evidently was
never actually tested with GUI dialogs, because trying to do that
revealed at least two (albeit minor) issues with what it did in that
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'.

Oh, you assume that the reader will not understand that
completing-read cannot possibly use GUI dialogs?  I'm okay with saying
that explicitly, although someone who uses these APIs must already
realize that.