bug#52877: [External] : Re: bug#52877: 27.2; Let `use-dialog-box' apply to more than just yes/no questions

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "larsi@gnus.org" <larsi@gnus.org>,
>         "52877@debbugs.gnu.org"
>       <52877@debbugs.gnu.org>
> Date: Sun, 16 Jan 2022 22:13:35 +0000
> 
> 2. This is a general request, to do what's suggested
>    for at least some commands that prompt for input
>    other than yes/no or y/n:
> 
>    When the system provides a dialog box for choosing
>    the input, let the command test `use-dialog-box',
>    and use that dialog box when that var is non-nil,
>    but use minibuffer input otherwise.
> 
>    Do this when it makes sense for a given command.
>    If it truly makes no sense for some particular
>    command - e.g., there's no way to get the required
>    input except by using a dialog box - then don't
>    try to do it for that command.

We already do that.  IMNSHO, it doesn't make sense in this particular
case.

> (defun set-frame-font-all (font)
>   "Set the default font to FONT on all existing and future frames.
> \(This is `set-frame-font' with `t' as argument FRAMES.)"
>   (interactive
>    (let* ((completion-ignore-case t)
>           (font (completing-read
>                "Font name: "
>                  (x-list-fonts "*" nil (selected-frame))

It is wrong to use (x-list-fonts "*" ...) to produce the collection
of fonts suitable for Emacs.

Yes, I know: you said it's just an example.  But providing an easy
example that cannot be extended to the Real Thing doesn't help us make
any progress of practical value.

> The point is more general than `menu-set-font'.  The
> point is that there's no good reason to limit the
> use of `use-dialog-box' to yes-no questions.

That we already do.