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

From: Eli Zaretskii <[email-masked]>
Date: Mon, 17 Jan 2022 14:47:28 +0200

> From: Drew Adams <[email-masked]>
> CC: "[email-masked]" <[email-masked]>,
>         "[email-masked]"
> 	<[email-masked]>
> 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.