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

From: Drew Adams <[email-masked]>
Date: Mon, 17 Jan 2022 17:18:31 +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.

"We already do that."  Really?  Please point to
examples of commands that use `use-dialog-box'
and prompt for input other than yes-no.

And if that's really the case, then please
correct the doc of `use-dialog-box', which says
"This applies to `y-or-n-p' and `yes-or-no-p'
questions asked by commands invoked by mouse
clicks and mouse menu items."

The two corrections would be (1) remove mention
of yes-no, or add "including" or "for example",
to make clear that use only _includes_ those 2
explicitly mentioned use cases and is not
limited to them, and (2) clarify that the
commands it applies to are commands that "can"
be invoked with the mouse.

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

"Wrong", meaning what, exactly?  I don't see
how it's wrong in the sense of not being able
to produce a collection of fonts suitable for
Emacs - it can certainly do that.

Perhaps you mean that it won't necessarily
produce a collection that includes _all_ such
fonts?  Or perhaps you mean that it can also
include fonts that are unsuitable for Emacs?
Please specify what you mean.

If there are any such qualifications they can
be called out in the doc string of the command,
to make users aware that, when `use-dialog-box'
is nil the set of candidate fonts is limited
in whatever particular way.

Such qualification doesn't at all make the
command useless.  I've used this for years,
to provide a set of font completion candidates:

(let ((fonts        (make-hash-table :test #'equal))
      (fontset-lst  (fontset-list)))
  (setq fontset-lst
        (delete
          "-*-*-*-*-*-*-*-*-*-*-*-*-fontset-default"
          fontset-lst))
  (dolist (ft (append fontset-lst
                      (x-list-fonts "*"))
                      fonts)
    (puthash ft t fonts)))

Doing better need not be held hostage to a
demand for perfection.

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

Whether you're interested in providing a command
that sets the font using either a dialog box or
keyboard input is irrelevant to this enhancement
request.  As is also any criticism of the code
I presented as an illustration.

Nothing about the enhancement request prevents
looking for cases where `use-dialog-box' could
reasonably be used to provide input to a command
by both menu/mouse and keyboard.

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

Examples?  And see above - if "we already do"
then please fix the doc string accordingly (in
addition to providing some such examples here).
___

FYI - This font-choosing example came from the
real world.  When presented with the possibility
of using keyboard input with completion to match
menu items (with their paths through the menu
forest), a user pointed out that although it
made it possible to choose menu items with the
keyboard, once an item such as setting the font
is chosen you have to switch to the mouse anyway,
to use the dialog box.

In general, you shouldn't have to.  In general,
`use-dialog-box' nil should allow for minibuffer
input instead.  By "in general", here, I don't
mean "always".

At least sometimes, and likely often, it should
be possible and reasonable to provide for
minibuffer input as an alternative to using a
dialog box.

Whether we decide to do that in any particular
case is a different question.  The point is that
it would be good to extend the use of
`use-dialog-box' beyond yes-no questions.