GNU bug report logs -
#52877
27.2; Let `use-dialog-box' apply to more than just yes/no questions
Previous Next
Reported by: Drew Adams <drew.adams <at> oracle.com>
Date: Wed, 29 Dec 2021 17:48:01 UTC
Severity: wishlist
Tags: notabug
Found in version 27.2
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 52877 in the body.
You can then email your comments to 52877 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52877; Package
emacs.
(Wed, 29 Dec 2021 17:48:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Drew Adams <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Wed, 29 Dec 2021 17:48:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52877; Package
emacs.
(Sat, 15 Jan 2022 10:03:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 52877 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> 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
Added tag(s) notabug.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sat, 15 Jan 2022 10:03:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
52877 <at> debbugs.gnu.org and Drew Adams <drew.adams <at> oracle.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sat, 15 Jan 2022 10:03:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52877; Package
emacs.
(Sat, 15 Jan 2022 22:13:02 GMT)
Full text and
rfc822 format available.
Message #15 received at 52877 <at> debbugs.gnu.org (full text, mbox):
> > 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52877; Package
emacs.
(Sun, 16 Jan 2022 08:51:01 GMT)
Full text and
rfc822 format available.
Message #18 received at 52877 <at> debbugs.gnu.org (full text, mbox):
> From: Drew Adams <drew.adams <at> oracle.com>
> Date: Sat, 15 Jan 2022 22:12:05 +0000
> Cc: "52877 <at> debbugs.gnu.org" <52877 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52877; Package
emacs.
(Sun, 16 Jan 2022 22:14:01 GMT)
Full text and
rfc822 format available.
Message #21 received at 52877 <at> debbugs.gnu.org (full text, mbox):
> > > 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52877; Package
emacs.
(Mon, 17 Jan 2022 12:49:02 GMT)
Full text and
rfc822 format available.
Message #24 received at 52877 <at> debbugs.gnu.org (full text, mbox):
> From: Drew Adams <drew.adams <at> oracle.com>
> CC: "larsi <at> gnus.org" <larsi <at> gnus.org>,
> "52877 <at> debbugs.gnu.org"
> <52877 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52877; Package
emacs.
(Mon, 17 Jan 2022 17:19:01 GMT)
Full text and
rfc822 format available.
Message #27 received at 52877 <at> debbugs.gnu.org (full text, mbox):
> > 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52877; Package
emacs.
(Mon, 17 Jan 2022 17:35:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 52877 <at> debbugs.gnu.org (full text, mbox):
> From: Drew Adams <drew.adams <at> oracle.com>
> CC: "larsi <at> gnus.org" <larsi <at> gnus.org>,
> "52877 <at> debbugs.gnu.org"
> <52877 <at> 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.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 15 Feb 2022 12:24:12 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 63 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.