* bug#52877: 27.2; Let `use-dialog-box' apply to more than just yes/no questions @ 2021-12-29 17:47 Drew Adams 2022-01-15 10:02 ` Lars Ingebrigtsen 0 siblings, 1 reply; 8+ messages in thread From: Drew Adams @ 2021-12-29 17:47 UTC (permalink / raw) To: 52877 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) ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#52877: 27.2; Let `use-dialog-box' apply to more than just yes/no questions 2021-12-29 17:47 bug#52877: 27.2; Let `use-dialog-box' apply to more than just yes/no questions Drew Adams @ 2022-01-15 10:02 ` Lars Ingebrigtsen 2022-01-15 22:12 ` bug#52877: [External] : " Drew Adams 0 siblings, 1 reply; 8+ messages in thread From: Lars Ingebrigtsen @ 2022-01-15 10:02 UTC (permalink / raw) To: Drew Adams; +Cc: 52877 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#52877: [External] : Re: bug#52877: 27.2; Let `use-dialog-box' apply to more than just yes/no questions 2022-01-15 10:02 ` Lars Ingebrigtsen @ 2022-01-15 22:12 ` Drew Adams 2022-01-16 8:50 ` Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: Drew Adams @ 2022-01-15 22:12 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 52877@debbugs.gnu.org > > 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? ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#52877: [External] : Re: bug#52877: 27.2; Let `use-dialog-box' apply to more than just yes/no questions 2022-01-15 22:12 ` bug#52877: [External] : " Drew Adams @ 2022-01-16 8:50 ` Eli Zaretskii 2022-01-16 22:13 ` Drew Adams 0 siblings, 1 reply; 8+ messages in thread From: Eli Zaretskii @ 2022-01-16 8:50 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, 52877 > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#52877: [External] : Re: bug#52877: 27.2; Let `use-dialog-box' apply to more than just yes/no questions 2022-01-16 8:50 ` Eli Zaretskii @ 2022-01-16 22:13 ` Drew Adams 2022-01-17 12:47 ` Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: Drew Adams @ 2022-01-16 22:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi@gnus.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. 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#52877: [External] : Re: bug#52877: 27.2; Let `use-dialog-box' apply to more than just yes/no questions 2022-01-16 22:13 ` Drew Adams @ 2022-01-17 12:47 ` Eli Zaretskii 2022-01-17 17:18 ` Drew Adams 0 siblings, 1 reply; 8+ messages in thread From: Eli Zaretskii @ 2022-01-17 12:47 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, 52877 > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#52877: [External] : Re: bug#52877: 27.2; Let `use-dialog-box' apply to more than just yes/no questions 2022-01-17 12:47 ` Eli Zaretskii @ 2022-01-17 17:18 ` Drew Adams 2022-01-17 17:34 ` Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: Drew Adams @ 2022-01-17 17:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi@gnus.org, 52877@debbugs.gnu.org > > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#52877: [External] : Re: bug#52877: 27.2; Let `use-dialog-box' apply to more than just yes/no questions 2022-01-17 17:18 ` Drew Adams @ 2022-01-17 17:34 ` Eli Zaretskii 0 siblings, 0 replies; 8+ messages in thread From: Eli Zaretskii @ 2022-01-17 17:34 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, 52877 > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-01-17 17:34 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-12-29 17:47 bug#52877: 27.2; Let `use-dialog-box' apply to more than just yes/no questions Drew Adams 2022-01-15 10:02 ` Lars Ingebrigtsen 2022-01-15 22:12 ` bug#52877: [External] : " Drew Adams 2022-01-16 8:50 ` Eli Zaretskii 2022-01-16 22:13 ` Drew Adams 2022-01-17 12:47 ` Eli Zaretskii 2022-01-17 17:18 ` Drew Adams 2022-01-17 17:34 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.