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

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

[Drew Adams]

A starting point is to redefine commands such as `menu-set-font', to
respect `use-dialog-box'.  For example:

(defun menu-set-font ()
  "Interactively select a font and make it the default on all frames.
The selected font will be the default on both the existing and future frames."
  (interactive)
  (if use-dialog-box
      (menu-set-font)
    (call-interactively #'set-frame-font-all)))

(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))
                                 nil nil nil nil
                                 (frame-parameter nil 'font))))
     (list font)))
  (set-frame-font font nil t))

If you prefer, instead of attempting the more general improvement of
commands that could respect `use-dialog-box', just fix `menu-set-font'
as indicated (or similarly).  But I think more commands that today
always raise a dialog box should be able to respect `use-dialog-box'.

In GNU Emacs 27.2 (build 1, x86_64-w64-mingw32)
 of 2021-03-26 built on CIRROCUMULUS
Repository revision: deef5efafb70f4b171265b896505b92b6eef24e6
Repository branch: HEAD
Windowing system distributor 'Microsoft Corp.', version 10.0.19042
System Description: Microsoft Windows 10 Pro (v10.0.2009.19042.1348)

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

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

> A starting point is to redefine commands such as `menu-set-font', to
> respect `use-dialog-box'.  For example:
>
> (defun menu-set-font ()
>   "Interactively select a font and make it the default on all frames.
> The selected font will be the default on both the existing and future frames."
>   (interactive)
>   (if use-dialog-box
>       (menu-set-font)
>     (call-interactively #'set-frame-font-all)))

If use-dialog-box is set, you want menu-set-font to call itself?

In any case, the current definition is:

(defun menu-set-font ()
  "Interactively select a font and make it the default on all frames.

The selected font will be the default on both the existing and future frames."
  (interactive)
  (set-frame-font (if (fboundp 'x-select-font)
		      (x-select-font)
		    (mouse-select-font))
		  nil t))

So it uses a graphical chooser by default, no matter whether
use-dialog-box is set or not.  So I don't think there's anything to fix
here, and I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Drew Adams]

> > A starting point is to redefine commands such as `menu-set-font', to
> > respect `use-dialog-box'.  For example:
> >
> > (defun menu-set-font ()
> >   "Interactively select a font and make it the default on all frames.
> > The selected font will be the default on both the existing and future
> > frames."
> >   (interactive)
> >   (if use-dialog-box
> >       (menu-set-font)
> >     (call-interactively #'set-frame-font-all)))
> 
> If use-dialog-box is set, you want menu-set-font to call itself?

The call inside the function should have been
`(current-definition-of-menu-set-font)'.

> In any case, the current definition is:...

Which is pretty much what it's always been.

> So it uses a graphical chooser by default, no matter whether
> use-dialog-box is set or not.

Exactly.  That's exactly the limitation this
enhancement request asks to remove.  Let _users_
control whether it uses a graphical chooser
or not - exactly what `use-dialog-box' is for.

The limitation is that `use-dialog-box' currently
is usable only with `yes-or-no' questions.

Clearly the `set-frame-font-all' code I showed,
together with the `use-dialog-box' test, should
have clued you in to what's being requested.
Alas, it apparently did not.

> So I don't think there's anything to fix
> here, and I'm closing this bug report.

Too bad.  This enhancement is not at all about
only `menu-set-font' - that was an illustration.

In your zeal to pointing out the typo in the
the `menu-set-font' definition did you perhaps
overlook the whole point?

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>
> Date: Sat, 15 Jan 2022 22:12:05 +0000
> Cc: "52877@debbugs.gnu.org" <52877@debbugs.gnu.org>
> 
> > So it uses a graphical chooser by default, no matter whether
> > use-dialog-box is set or not.
> 
> Exactly.  That's exactly the limitation this
> enhancement request asks to remove.  Let _users_
> control whether it uses a graphical chooser
> or not - exactly what `use-dialog-box' is for.
> 
> The limitation is that `use-dialog-box' currently
> is usable only with `yes-or-no' questions.

We don't provide any non-dialog way of selecting fonts because no one
has written code to do that.  The dialog we show uses OS APIs, and the
implementation, beyond popping up the dialog and using the value it
returns, is not in Emacs.

So we simply cannot offer the users control of this, since we don't
have code to find the available fonts relevant to Emacs and display
them grouped by family, typeface, size, etc., in a useful way.  We use
the system-provided dialogs instead.

IOW, this is not a bug.

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

[Drew Adams]

> > > So it uses a graphical chooser by default, 
> > > no matter whether use-dialog-box is set or not.
> >
> > Exactly.  That's exactly the limitation this
> > enhancement request asks to remove.  Let _users_
> > control whether it uses a graphical chooser
> > or not - exactly what `use-dialog-box' is for.
> >
> > The limitation is that `use-dialog-box' currently
> > is usable only with `yes-or-no' questions.
> 
> We don't provide any non-dialog way of selecting fonts because no one
> has written code to do that.  The dialog we show uses OS APIs, and the
> implementation, beyond popping up the dialog and using the value it
> returns, is not in Emacs.
> 
> So we simply cannot offer the users control of this, since we don't
> have code to find the available fonts relevant to Emacs and display
> them grouped by family, typeface, size, etc., in a useful way.  We use
> the system-provided dialogs instead.
> 
> IOW, this is not a bug.

Let me try again to be clear.

1. This is an enhancement request, NOT a bug report.

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.

3. As an _illustration_, and as a possible starting
   point, do this for `menu-set-font' (which could,
   but need not, be renamed to remove "menu").

This code does that.  It uses the current code for
that command only when `use-dialog-box' is non-nil.
It instead uses the minibuffer with completion when
the option is nil.

(defun menu-set-font ()
  "Interactively select a font and make it the default on all frames.
The selected font will be the default on both the existing and future frames."
  (interactive)
  (if use-dialog-box
      (set-frame-font (if (fboundp 'x-select-font)
			  (x-select-font)
			(mouse-select-font))
		      nil t)
    (call-interactively #'set-frame-font-all)))

(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))
                 nil nil nil nil
                 (frame-parameter nil 'font))))
     (list font)))
  (set-frame-font font nil t))

AFAICT, at least on MS Windows, it just works.  But if
you feel it doesn't work as you'd prefer, feel free to
use other code.

As for whether the simple code I suggested here for
`set-frame-font-all' provides _exactly_ what the use
of the dialog box provides (you mention grouping fonts
"by family, typeface, size, etc., in a useful way"):
that's not very relevant - not definitively limiting.
The doc of the command can make clear what the behavior
is in each case, if they differ: graphic input vs
minibuffer input.

In any case, the point is not this particular code.

The point is not even, more generally, to fix
`menu-set-font' to make it usable also with nil
`use-dialog-box' (using the minibuffer in that case).

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.

But if you think there is such a reason, which
precludes _any_ use, for _any_ non-yes-or-no command,
to use `use-dialog-box, then please state the reason.

Users should be able to make at least some commands,
which today _always_ use a dialog box, respect
`use-dialog-box', so that if nil they prompt and
accept minibuffer input.

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.

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

[Drew Adams]

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

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: Mon, 17 Jan 2022 17:18:31 +0000
> 
> > 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.

You can find them yourself by searching the Emacs source tree.

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

Try looking at the list it returns some day, but look really close
(it's a large list).

> Perhaps you mean that it won't necessarily
> produce a collection that includes _all_ such
> fonts?

No, I mean many fonts it produces are unusable in Emacs.

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

So you used it.  It only proves that on your systems, with the fonts
you have, and with the way you used the results it somehow worked.  Or
maybe you just happily forgot when it didn't.  It doesn't change the
facts: that list includes many unsuitable fonts.  Please believe me,
and please stop arguing.