* discoverability, better defaults and which-key in Emacs @ 2024-01-31 23:23 Jeremy Bryant 2024-02-01 2:45 ` Po Lu 2024-02-01 7:35 ` Eli Zaretskii 0 siblings, 2 replies; 78+ messages in thread From: Jeremy Bryant @ 2024-01-31 23:23 UTC (permalink / raw) To: justin, Emacs Devel A recent theme of discussion has been improving discoverability of Emacs features, and in a related way, 'better defaults'. Here is a suggestion - include which-key in core and potentially enable by for new users. I understand it is in ELPA already. Author Justin has expressed openness to the idea in https://github.com/justbur/emacs-which-key/issues/355 What do people think? What work needs to be done and how? ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-01-31 23:23 discoverability, better defaults and which-key in Emacs Jeremy Bryant @ 2024-02-01 2:45 ` Po Lu 2024-02-03 13:40 ` Philip Kaludercic 2024-02-01 7:35 ` Eli Zaretskii 1 sibling, 1 reply; 78+ messages in thread From: Po Lu @ 2024-02-01 2:45 UTC (permalink / raw) To: Jeremy Bryant; +Cc: justin, Emacs Devel Jeremy Bryant <jb@jeremybryant.net> writes: > Here is a suggestion - include which-key in core and potentially enable > by for new users. > > I understand it is in ELPA already. > > Author Justin has expressed openness to the idea in > https://github.com/justbur/emacs-which-key/issues/355 I don't think enabling it by default is all that desirable, since its popups are far more intrusive than keystrokes are when echoed, but moving it to core is a decent idea. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-01 2:45 ` Po Lu @ 2024-02-03 13:40 ` Philip Kaludercic 2024-02-04 22:03 ` Dmitry Gutov 0 siblings, 1 reply; 78+ messages in thread From: Philip Kaludercic @ 2024-02-03 13:40 UTC (permalink / raw) To: Po Lu; +Cc: Jeremy Bryant, justin, Emacs Devel Po Lu <luangruo@yahoo.com> writes: > Jeremy Bryant <jb@jeremybryant.net> writes: > >> Here is a suggestion - include which-key in core and potentially enable >> by for new users. >> >> I understand it is in ELPA already. >> >> Author Justin has expressed openness to the idea in >> https://github.com/justbur/emacs-which-key/issues/355 > > I don't think enabling it by default is all that desirable, since its > popups are far more intrusive than keystrokes are when echoed, but > moving it to core is a decent idea. I second this concern, it also promotes the inefficient practice of inspecting keymaps by waiting for the idle timer to be triggered. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-03 13:40 ` Philip Kaludercic @ 2024-02-04 22:03 ` Dmitry Gutov 2024-02-05 7:11 ` Philip Kaludercic 0 siblings, 1 reply; 78+ messages in thread From: Dmitry Gutov @ 2024-02-04 22:03 UTC (permalink / raw) To: Philip Kaludercic, Po Lu; +Cc: Jeremy Bryant, justin, Emacs Devel On 03/02/2024 15:40, Philip Kaludercic wrote: > Po Lu<luangruo@yahoo.com> writes: > >> Jeremy Bryant<jb@jeremybryant.net> writes: >> >>> Here is a suggestion - include which-key in core and potentially enable >>> by for new users. >>> >>> I understand it is in ELPA already. >>> >>> Author Justin has expressed openness to the idea in >>> https://github.com/justbur/emacs-which-key/issues/355 >> I don't think enabling it by default is all that desirable, since its >> popups are far more intrusive than keystrokes are when echoed, but >> moving it to core is a decent idea. > I second this concern, it also promotes the inefficient practice of > inspecting keymaps by waiting for the idle timer to be triggered. What if instead of having the help on a timer, the timer would add a small hint in the echo about how to invoke help (i.e. press C-h)? The interface for displaying help could be which-key (it seems to look pretty enough), or just the current 'C-h' help, depending on the settings. The result, though, is that everybody learns to press 'C-h' when they want to explore what the current prefix map contains and not just wait for the timer. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-04 22:03 ` Dmitry Gutov @ 2024-02-05 7:11 ` Philip Kaludercic 2024-02-05 15:38 ` Dmitry Gutov 0 siblings, 1 reply; 78+ messages in thread From: Philip Kaludercic @ 2024-02-05 7:11 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Po Lu, Jeremy Bryant, justin, Emacs Devel Dmitry Gutov <dmitry@gutov.dev> writes: > On 03/02/2024 15:40, Philip Kaludercic wrote: >> Po Lu<luangruo@yahoo.com> writes: >> >>> Jeremy Bryant<jb@jeremybryant.net> writes: >>> >>>> Here is a suggestion - include which-key in core and potentially enable >>>> by for new users. >>>> >>>> I understand it is in ELPA already. >>>> >>>> Author Justin has expressed openness to the idea in >>>> https://github.com/justbur/emacs-which-key/issues/355 >>> I don't think enabling it by default is all that desirable, since its >>> popups are far more intrusive than keystrokes are when echoed, but >>> moving it to core is a decent idea. >> I second this concern, it also promotes the inefficient practice of >> inspecting keymaps by waiting for the idle timer to be triggered. > > What if instead of having the help on a timer, the timer would add a > small hint in the echo about how to invoke help (i.e. press C-h)? I think that would be a significant improvement if it is to be enabled by default. I don't have an issue with the presentation (though the transient buffer is my preferred UX). > The interface for displaying help could be which-key (it seems to look > pretty enough), or just the current 'C-h' help, depending on the > settings. > > The result, though, is that everybody learns to press 'C-h' when they > want to explore what the current prefix map contains and not just wait > for the timer. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-05 7:11 ` Philip Kaludercic @ 2024-02-05 15:38 ` Dmitry Gutov 2024-02-05 18:47 ` Philip Kaludercic 0 siblings, 1 reply; 78+ messages in thread From: Dmitry Gutov @ 2024-02-05 15:38 UTC (permalink / raw) To: Philip Kaludercic; +Cc: Po Lu, Jeremy Bryant, justin, Emacs Devel On 05/02/2024 09:11, Philip Kaludercic wrote: > Dmitry Gutov <dmitry@gutov.dev> writes: > >> On 03/02/2024 15:40, Philip Kaludercic wrote: >>> Po Lu<luangruo@yahoo.com> writes: >>> >>>> Jeremy Bryant<jb@jeremybryant.net> writes: >>>> >>>>> Here is a suggestion - include which-key in core and potentially enable >>>>> by for new users. >>>>> >>>>> I understand it is in ELPA already. >>>>> >>>>> Author Justin has expressed openness to the idea in >>>>> https://github.com/justbur/emacs-which-key/issues/355 >>>> I don't think enabling it by default is all that desirable, since its >>>> popups are far more intrusive than keystrokes are when echoed, but >>>> moving it to core is a decent idea. >>> I second this concern, it also promotes the inefficient practice of >>> inspecting keymaps by waiting for the idle timer to be triggered. >> >> What if instead of having the help on a timer, the timer would add a >> small hint in the echo about how to invoke help (i.e. press C-h)? > > I think that would be a significant improvement if it is to be enabled > by default. I don't have an issue with the presentation (though the > transient buffer is my preferred UX). Is "transient buffer" the same as what which-key uses? I think the 'transient' package uses similar display. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-05 15:38 ` Dmitry Gutov @ 2024-02-05 18:47 ` Philip Kaludercic 2024-02-05 19:17 ` Dmitry Gutov 0 siblings, 1 reply; 78+ messages in thread From: Philip Kaludercic @ 2024-02-05 18:47 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Po Lu, Jeremy Bryant, justin, Emacs Devel Dmitry Gutov <dmitry@gutov.dev> writes: > On 05/02/2024 09:11, Philip Kaludercic wrote: >> Dmitry Gutov <dmitry@gutov.dev> writes: >> >>> On 03/02/2024 15:40, Philip Kaludercic wrote: >>>> Po Lu<luangruo@yahoo.com> writes: >>>> >>>>> Jeremy Bryant<jb@jeremybryant.net> writes: >>>>> >>>>>> Here is a suggestion - include which-key in core and potentially enable >>>>>> by for new users. >>>>>> >>>>>> I understand it is in ELPA already. >>>>>> >>>>>> Author Justin has expressed openness to the idea in >>>>>> https://github.com/justbur/emacs-which-key/issues/355 >>>>> I don't think enabling it by default is all that desirable, since its >>>>> popups are far more intrusive than keystrokes are when echoed, but >>>>> moving it to core is a decent idea. >>>> I second this concern, it also promotes the inefficient practice of >>>> inspecting keymaps by waiting for the idle timer to be triggered. >>> >>> What if instead of having the help on a timer, the timer would add a >>> small hint in the echo about how to invoke help (i.e. press C-h)? >> I think that would be a significant improvement if it is to be >> enabled >> by default. I don't have an issue with the presentation (though the >> transient buffer is my preferred UX). > > Is "transient buffer" the same as what which-key uses? I think the > 'transient' package uses similar display. I don't know, what I meant with transient buffer is that it isn't persistent, as is the case with C-h C-h where a new window pops up that is no different than any other window and behaves consistently. Transient buffers, in my experience, usually gobble up all key-presses and re-implement their own "MVC" that can differ in subtle points. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-05 18:47 ` Philip Kaludercic @ 2024-02-05 19:17 ` Dmitry Gutov 2024-02-05 19:33 ` Justin Burkett 0 siblings, 1 reply; 78+ messages in thread From: Dmitry Gutov @ 2024-02-05 19:17 UTC (permalink / raw) To: Philip Kaludercic; +Cc: Po Lu, Jeremy Bryant, justin, Emacs Devel On 05/02/2024 20:47, Philip Kaludercic wrote: >>>> What if instead of having the help on a timer, the timer would add a >>>> small hint in the echo about how to invoke help (i.e. press C-h)? >>> I think that would be a significant improvement if it is to be >>> enabled >>> by default. I don't have an issue with the presentation (though the >>> transient buffer is my preferred UX). >> Is "transient buffer" the same as what which-key uses? I think the >> 'transient' package uses similar display. > I don't know, what I meant with transient buffer is that it isn't > persistent, as is the case with C-h C-h where a new window pops up that > is no different than any other window and behaves consistently. > Transient buffers, in my experience, usually gobble up all key-presses > and re-implement their own "MVC" that can differ in subtle points. What I'm wondering, is where to do from here. If you like which-key's UI (and I don't mind it, aside from the timer thing -- seems like it can be more useful than the current 'describe-bindings' in many cases), then we could ask the author for this different mode of operation, where the timer only tells the user how to get this transient menu with hints (pressing C-h), but the menu itself isn't shown. Or more generally we'll have such a timer globally, and the message ("use C-h") would be independent from which-key. But which-key can plug into the "C-h" binding one way or another, to replace describe-bindings if the user configured it this way. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-05 19:17 ` Dmitry Gutov @ 2024-02-05 19:33 ` Justin Burkett 2024-02-05 23:05 ` Dmitry Gutov 0 siblings, 1 reply; 78+ messages in thread From: Justin Burkett @ 2024-02-05 19:33 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Philip Kaludercic, Po Lu, Jeremy Bryant, Emacs Devel > If you like which-key's UI (and I don't mind it, aside from the timer > thing -- seems like it can be more useful than the current > 'describe-bindings' in many cases), then we could ask the author for > this different mode of operation, where the timer only tells the user > how to get this transient menu with hints (pressing C-h), but the menu > itself isn't shown. > > Or more generally we'll have such a timer globally, and the message > ("use C-h") would be independent from which-key. But which-key can plug > into the "C-h" binding one way or another, to replace describe-bindings > if the user configured it this way. I'm the author of which-key, and I've been following along but don't have a strong opinion on whether it should be on by default, so I'll let you all decide. I should mention in response to the comments above that this feature is partially implemented through the following setup (from the README). It simply sets a long delay for the timer and allows you to use C-h to trigger the popup. ;; Allow C-h to trigger which-key before it is done automatically (setq which-key-show-early-on-C-h t) ;; make sure which-key doesn't show normally but refreshes quickly after it is ;; triggered. (setq which-key-idle-delay 10000) (setq which-key-idle-secondary-delay 0.05) (which-key-mode) Justin On Mon, Feb 5, 2024 at 2:17 PM Dmitry Gutov <dmitry@gutov.dev> wrote: > > On 05/02/2024 20:47, Philip Kaludercic wrote: > >>>> What if instead of having the help on a timer, the timer would add a > >>>> small hint in the echo about how to invoke help (i.e. press C-h)? > >>> I think that would be a significant improvement if it is to be > >>> enabled > >>> by default. I don't have an issue with the presentation (though the > >>> transient buffer is my preferred UX). > >> Is "transient buffer" the same as what which-key uses? I think the > >> 'transient' package uses similar display. > > I don't know, what I meant with transient buffer is that it isn't > > persistent, as is the case with C-h C-h where a new window pops up that > > is no different than any other window and behaves consistently. > > Transient buffers, in my experience, usually gobble up all key-presses > > and re-implement their own "MVC" that can differ in subtle points. > > What I'm wondering, is where to do from here. > > If you like which-key's UI (and I don't mind it, aside from the timer > thing -- seems like it can be more useful than the current > 'describe-bindings' in many cases), then we could ask the author for > this different mode of operation, where the timer only tells the user > how to get this transient menu with hints (pressing C-h), but the menu > itself isn't shown. > > Or more generally we'll have such a timer globally, and the message > ("use C-h") would be independent from which-key. But which-key can plug > into the "C-h" binding one way or another, to replace describe-bindings > if the user configured it this way. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-05 19:33 ` Justin Burkett @ 2024-02-05 23:05 ` Dmitry Gutov 2024-02-06 2:49 ` Justin Burkett 0 siblings, 1 reply; 78+ messages in thread From: Dmitry Gutov @ 2024-02-05 23:05 UTC (permalink / raw) To: Justin Burkett; +Cc: Philip Kaludercic, Po Lu, Jeremy Bryant, Emacs Devel On 05/02/2024 21:33, Justin Burkett wrote: >> If you like which-key's UI (and I don't mind it, aside from the timer >> thing -- seems like it can be more useful than the current >> 'describe-bindings' in many cases), then we could ask the author for >> this different mode of operation, where the timer only tells the user >> how to get this transient menu with hints (pressing C-h), but the menu >> itself isn't shown. >> >> Or more generally we'll have such a timer globally, and the message >> ("use C-h") would be independent from which-key. But which-key can plug >> into the "C-h" binding one way or another, to replace describe-bindings >> if the user configured it this way. > I'm the author of which-key, and I've been following along but don't > have a strong opinion on whether it should be on by default, so I'll > let you all decide. > > I should mention in response to the comments above that this feature > is partially implemented through the following setup (from the > README). It simply sets a long delay for the timer and allows you to > use C-h to trigger the popup. > > ;; Allow C-h to trigger which-key before it is done automatically > (setq which-key-show-early-on-C-h t) > ;; make sure which-key doesn't show normally but refreshes > quickly after it is > ;; triggered. > (setq which-key-idle-delay 10000) > (setq which-key-idle-secondary-delay 0.05) > (which-key-mode) Nice, thanks. These settings are for the second option, right? "More generally ...", etc. What is missing is the note in the echo area that tells the user to press C-h after a timeout (like 200ms or so) if they want help in the middle of typing a key sequence. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-05 23:05 ` Dmitry Gutov @ 2024-02-06 2:49 ` Justin Burkett 2024-02-06 23:12 ` Dmitry Gutov 0 siblings, 1 reply; 78+ messages in thread From: Justin Burkett @ 2024-02-06 2:49 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Philip Kaludercic, Po Lu, Jeremy Bryant, Emacs Devel On Mon, Feb 5, 2024 at 6:05 PM Dmitry Gutov <dmitry@gutov.dev> wrote: > > On 05/02/2024 21:33, Justin Burkett wrote: > >> If you like which-key's UI (and I don't mind it, aside from the timer > >> thing -- seems like it can be more useful than the current > >> 'describe-bindings' in many cases), then we could ask the author for > >> this different mode of operation, where the timer only tells the user > >> how to get this transient menu with hints (pressing C-h), but the menu > >> itself isn't shown. > >> > >> Or more generally we'll have such a timer globally, and the message > >> ("use C-h") would be independent from which-key. But which-key can plug > >> into the "C-h" binding one way or another, to replace describe-bindings > >> if the user configured it this way. > > I'm the author of which-key, and I've been following along but don't > > have a strong opinion on whether it should be on by default, so I'll > > let you all decide. > > > > I should mention in response to the comments above that this feature > > is partially implemented through the following setup (from the > > README). It simply sets a long delay for the timer and allows you to > > use C-h to trigger the popup. > > > > ;; Allow C-h to trigger which-key before it is done automatically > > (setq which-key-show-early-on-C-h t) > > ;; make sure which-key doesn't show normally but refreshes > > quickly after it is > > ;; triggered. > > (setq which-key-idle-delay 10000) > > (setq which-key-idle-secondary-delay 0.05) > > (which-key-mode) > > Nice, thanks. These settings are for the second option, right? "More > generally ...", etc. > > What is missing is the note in the echo area that tells the user to > press C-h after a timeout (like 200ms or so) if they want help in the > middle of typing a key sequence. True, but I think a message like that could be useful regardless of whether which-key is active (i.e., for `describe-prefix-bindings`). ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-06 2:49 ` Justin Burkett @ 2024-02-06 23:12 ` Dmitry Gutov 2024-02-07 12:35 ` Eli Zaretskii 0 siblings, 1 reply; 78+ messages in thread From: Dmitry Gutov @ 2024-02-06 23:12 UTC (permalink / raw) To: Justin Burkett; +Cc: Philip Kaludercic, Po Lu, Jeremy Bryant, Emacs Devel [-- Attachment #1: Type: text/plain, Size: 535 bytes --] On 06/02/2024 04:49, Justin Burkett wrote: >> What is missing is the note in the echo area that tells the user to >> press C-h after a timeout (like 200ms or so) if they want help in the >> middle of typing a key sequence. > True, but I think a message like that could be useful regardless of > whether which-key is active (i.e., for `describe-prefix-bindings`). Right. :) How about this? Since echo-keystrokes is 1 second by default, which defines a significant timeout already, I think this can work without a yet another timer. [-- Attachment #2: echo_keystrokes_help.diff --] [-- Type: text/x-patch, Size: 1067 bytes --] diff --git a/src/keyboard.c b/src/keyboard.c index 1f7253a7da1..6d3db5ab615 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -589,6 +589,15 @@ echo_dash (void) AUTO_STRING (dash, "-"); kset_echo_string (current_kboard, concat2 (KVAR (current_kboard, echo_string), dash)); + + if (echo_keystrokes_help) + { + AUTO_STRING (help, " (\\`C-h' for help)"); + kset_echo_string (current_kboard, + concat2 (KVAR (current_kboard, echo_string), + calln (Qsubstitute_command_keys, help))); + } + echo_now (); } @@ -13228,6 +13237,10 @@ syms_of_keyboard (void) If the value is zero, don't echo at all. */); Vecho_keystrokes = make_fixnum (1); + DEFVAR_BOOL ("echo-keystrokes-help", echo_keystrokes_help, + doc: /* Non-nil means append small help text to the unfinished commands' echo. */); + echo_keystrokes_help = true; + DEFVAR_LISP ("polling-period", Vpolling_period, doc: /* Interval between polling for input during Lisp execution. The reason for polling is to make C-g work to stop a running program. ^ permalink raw reply related [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-06 23:12 ` Dmitry Gutov @ 2024-02-07 12:35 ` Eli Zaretskii 2024-02-07 18:31 ` Dmitry Gutov 0 siblings, 1 reply; 78+ messages in thread From: Eli Zaretskii @ 2024-02-07 12:35 UTC (permalink / raw) To: Dmitry Gutov; +Cc: justin, philipk, luangruo, jb, emacs-devel > Date: Wed, 7 Feb 2024 01:12:37 +0200 > Cc: Philip Kaludercic <philipk@posteo.net>, Po Lu <luangruo@yahoo.com>, > Jeremy Bryant <jb@jeremybryant.net>, Emacs Devel <emacs-devel@gnu.org> > From: Dmitry Gutov <dmitry@gutov.dev> > > How about this? > > Since echo-keystrokes is 1 second by default, which defines a > significant timeout already, I think this can work without a yet another > timer. LGTM, but it should be a defcustom. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-07 12:35 ` Eli Zaretskii @ 2024-02-07 18:31 ` Dmitry Gutov 2024-02-07 19:13 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 78+ messages in thread From: Dmitry Gutov @ 2024-02-07 18:31 UTC (permalink / raw) To: Eli Zaretskii; +Cc: justin, philipk, luangruo, jb, emacs-devel [-- Attachment #1: Type: text/plain, Size: 520 bytes --] On 07/02/2024 14:35, Eli Zaretskii wrote: >> Date: Wed, 7 Feb 2024 01:12:37 +0200 >> Cc: Philip Kaludercic <philipk@posteo.net>, Po Lu <luangruo@yahoo.com>, >> Jeremy Bryant <jb@jeremybryant.net>, Emacs Devel <emacs-devel@gnu.org> >> From: Dmitry Gutov <dmitry@gutov.dev> >> >> How about this? >> >> Since echo-keystrokes is 1 second by default, which defines a >> significant timeout already, I think this can work without a yet another >> timer. > > LGTM, but it should be a defcustom. All right, see the attached. [-- Attachment #2: echo_keystrokes_help.diff --] [-- Type: text/x-patch, Size: 2055 bytes --] diff --git a/etc/NEWS b/etc/NEWS index ee7462cb2aa..d4b8bf21f94 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -307,6 +307,9 @@ between the auto save file and the current file. ** 'ffap-lax-url' now defaults to nil. Previously, it was set to t but this broke remote file name detection. +** Unfinished commands' echo now ends with a suggestion to use Help +Customize 'echo-keystrokes-help' to nil to hide it. + \f * Editing Changes in Emacs 30.1 diff --git a/lisp/cus-start.el b/lisp/cus-start.el index 7e0b64e9067..3fe62c8d0da 100644 --- a/lisp/cus-start.el +++ b/lisp/cus-start.el @@ -371,6 +371,7 @@ minibuffer-prompt-properties--setter (auto-save-timeout auto-save (choice (const :tag "off" nil) (integer :format "%v"))) (echo-keystrokes minibuffer number) + (echo-keystrokes-help minibuffer boolean "30.1") (polling-period keyboard float) (double-click-time mouse (restricted-sexp :match-alternatives (integerp 'nil 't))) diff --git a/src/keyboard.c b/src/keyboard.c index 1f7253a7da1..6d3db5ab615 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -589,6 +589,15 @@ echo_dash (void) AUTO_STRING (dash, "-"); kset_echo_string (current_kboard, concat2 (KVAR (current_kboard, echo_string), dash)); + + if (echo_keystrokes_help) + { + AUTO_STRING (help, " (\\`C-h' for help)"); + kset_echo_string (current_kboard, + concat2 (KVAR (current_kboard, echo_string), + calln (Qsubstitute_command_keys, help))); + } + echo_now (); } @@ -13228,6 +13237,10 @@ syms_of_keyboard (void) If the value is zero, don't echo at all. */); Vecho_keystrokes = make_fixnum (1); + DEFVAR_BOOL ("echo-keystrokes-help", echo_keystrokes_help, + doc: /* Non-nil means append small help text to the unfinished commands' echo. */); + echo_keystrokes_help = true; + DEFVAR_LISP ("polling-period", Vpolling_period, doc: /* Interval between polling for input during Lisp execution. The reason for polling is to make C-g work to stop a running program. ^ permalink raw reply related [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-07 18:31 ` Dmitry Gutov @ 2024-02-07 19:13 ` Eli Zaretskii 2024-02-07 19:51 ` Dmitry Gutov 2024-02-08 1:46 ` Visuwesh 2024-02-08 13:25 ` discoverability, better defaults and which-key in Emacs Po Lu 2 siblings, 1 reply; 78+ messages in thread From: Eli Zaretskii @ 2024-02-07 19:13 UTC (permalink / raw) To: Dmitry Gutov; +Cc: justin, philipk, luangruo, jb, emacs-devel > Date: Wed, 7 Feb 2024 20:31:04 +0200 > Cc: justin@burkett.cc, philipk@posteo.net, luangruo@yahoo.com, > jb@jeremybryant.net, emacs-devel@gnu.org > From: Dmitry Gutov <dmitry@gutov.dev> > > > LGTM, but it should be a defcustom. > > All right, see the attached. Thanks. Nitpicking: > --- a/etc/NEWS > +++ b/etc/NEWS > @@ -307,6 +307,9 @@ between the auto save file and the current file. > ** 'ffap-lax-url' now defaults to nil. > Previously, it was set to t but this broke remote file name detection. > > +** Unfinished commands' echo now ends with a suggestion to use Help Heading lines in NEWS should end with a period. > +Customize 'echo-keystrokes-help' to nil to hide it. ^^^^^^^^^^ "to prevent it" is better, I think. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-07 19:13 ` Eli Zaretskii @ 2024-02-07 19:51 ` Dmitry Gutov 0 siblings, 0 replies; 78+ messages in thread From: Dmitry Gutov @ 2024-02-07 19:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: justin, philipk, luangruo, jb, emacs-devel On 07/02/2024 21:13, Eli Zaretskii wrote: >> Date: Wed, 7 Feb 2024 20:31:04 +0200 >> Cc:justin@burkett.cc,philipk@posteo.net,luangruo@yahoo.com, >> jb@jeremybryant.net,emacs-devel@gnu.org >> From: Dmitry Gutov<dmitry@gutov.dev> >> >>> LGTM, but it should be a defcustom. >> All right, see the attached. > Thanks. Nitpicking: > >> --- a/etc/NEWS >> +++ b/etc/NEWS >> @@ -307,6 +307,9 @@ between the auto save file and the current file. >> ** 'ffap-lax-url' now defaults to nil. >> Previously, it was set to t but this broke remote file name detection. >> >> +** Unfinished commands' echo now ends with a suggestion to use Help > Heading lines in NEWS should end with a period. > >> +Customize 'echo-keystrokes-help' to nil to hide it. > ^^^^^^^^^^ > "to prevent it" is better, I think. Thanks for the comments, pushed to master as f444786e587. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-07 18:31 ` Dmitry Gutov 2024-02-07 19:13 ` Eli Zaretskii @ 2024-02-08 1:46 ` Visuwesh 2024-02-08 6:59 ` Eli Zaretskii 2024-02-08 13:25 ` discoverability, better defaults and which-key in Emacs Po Lu 2 siblings, 1 reply; 78+ messages in thread From: Visuwesh @ 2024-02-08 1:46 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Eli Zaretskii, justin, philipk, luangruo, jb, emacs-devel [புதன் பிப்ரவரி 07, 2024] Dmitry Gutov wrote: > [...] > diff --git a/src/keyboard.c b/src/keyboard.c > index 1f7253a7da1..6d3db5ab615 100644 > --- a/src/keyboard.c > +++ b/src/keyboard.c > @@ -589,6 +589,15 @@ echo_dash (void) > AUTO_STRING (dash, "-"); > kset_echo_string (current_kboard, > concat2 (KVAR (current_kboard, echo_string), dash)); > + > + if (echo_keystrokes_help) > + { > + AUTO_STRING (help, " (\\`C-h' for help)"); ^^^^^^^ Shouldn't this part use the value of help-char instead? (There's also the complication with help-form.) > + kset_echo_string (current_kboard, > + concat2 (KVAR (current_kboard, echo_string), > + calln (Qsubstitute_command_keys, help))); > + } > + > echo_now (); > } > > @@ -13228,6 +13237,10 @@ syms_of_keyboard (void) > If the value is zero, don't echo at all. */); > Vecho_keystrokes = make_fixnum (1); > > + DEFVAR_BOOL ("echo-keystrokes-help", echo_keystrokes_help, > + doc: /* Non-nil means append small help text to the unfinished commands' echo. */); > + echo_keystrokes_help = true; > + > DEFVAR_LISP ("polling-period", Vpolling_period, > doc: /* Interval between polling for input during Lisp execution. > The reason for polling is to make C-g work to stop a running program. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-08 1:46 ` Visuwesh @ 2024-02-08 6:59 ` Eli Zaretskii 2024-02-08 12:18 ` Dmitry Gutov 0 siblings, 1 reply; 78+ messages in thread From: Eli Zaretskii @ 2024-02-08 6:59 UTC (permalink / raw) To: Visuwesh; +Cc: dmitry, justin, philipk, luangruo, jb, emacs-devel > From: Visuwesh <visuweshm@gmail.com> > Cc: Eli Zaretskii <eliz@gnu.org>, justin@burkett.cc, philipk@posteo.net, > luangruo@yahoo.com, jb@jeremybryant.net, emacs-devel@gnu.org > Date: Thu, 08 Feb 2024 07:16:56 +0530 > > [புதன் பிப்ரவரி 07, 2024] Dmitry Gutov wrote: > > > [...] > > diff --git a/src/keyboard.c b/src/keyboard.c > > index 1f7253a7da1..6d3db5ab615 100644 > > --- a/src/keyboard.c > > +++ b/src/keyboard.c > > @@ -589,6 +589,15 @@ echo_dash (void) > > AUTO_STRING (dash, "-"); > > kset_echo_string (current_kboard, > > concat2 (KVAR (current_kboard, echo_string), dash)); > > + > > + if (echo_keystrokes_help) > > + { > > + AUTO_STRING (help, " (\\`C-h' for help)"); > ^^^^^^^ > > Shouldn't this part use the value of help-char instead? (There's also > the complication with help-form.) I'm not sure using help-char here is TRT: that character is only in effect in this situation of it has no binding prefixed by what the user already typed. So the effect of changing help-char could be confusing for newbies, who are the main audience of this feature. But I added F1 to that text, which should help if someone did change help-char. Thanks. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-08 6:59 ` Eli Zaretskii @ 2024-02-08 12:18 ` Dmitry Gutov 2024-02-08 13:02 ` Eli Zaretskii 0 siblings, 1 reply; 78+ messages in thread From: Dmitry Gutov @ 2024-02-08 12:18 UTC (permalink / raw) To: Eli Zaretskii, Visuwesh; +Cc: justin, philipk, luangruo, jb, emacs-devel On 08/02/2024 08:59, Eli Zaretskii wrote: > But > I added F1 to that text, which should help if someone did change > help-char. Whether help-char is changed, or 'C-h' is rebound anyway, can all be detected at runtime. <f1> can also have a different binding in the current prefix map--then the new message would be doubly incorrect. I'd rather we picked one (preferably correct) suggestion and printed that. For context: I customize echo-keystrokes to a very low value and currently see this help message quite often. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-08 12:18 ` Dmitry Gutov @ 2024-02-08 13:02 ` Eli Zaretskii 2024-02-08 13:36 ` Dmitry Gutov ` (2 more replies) 0 siblings, 3 replies; 78+ messages in thread From: Eli Zaretskii @ 2024-02-08 13:02 UTC (permalink / raw) To: Dmitry Gutov; +Cc: visuweshm, justin, philipk, luangruo, jb, emacs-devel > Date: Thu, 8 Feb 2024 14:18:34 +0200 > Cc: justin@burkett.cc, philipk@posteo.net, luangruo@yahoo.com, > jb@jeremybryant.net, emacs-devel@gnu.org > From: Dmitry Gutov <dmitry@gutov.dev> > > On 08/02/2024 08:59, Eli Zaretskii wrote: > > But > > I added F1 to that text, which should help if someone did change > > help-char. > > Whether help-char is changed, or 'C-h' is rebound anyway, can all be > detected at runtime. <f1> can also have a different binding in the > current prefix map--then the new message would be doubly incorrect. How frequently do people rebind F1? IME, never. But I don't object to adding runtime detection of the help keys. > I'd rather we picked one (preferably correct) suggestion and printed that. Most people will never rebind C-h. Those who do could rebind it to a character that cannot be used in this situation because it is already bound in various prefix maps. Having two alternatives there increases the probability that one of them will work. > For context: I customize echo-keystrokes to a very low value and > currently see this help message quite often. If the message annoys you, you can disable it. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-08 13:02 ` Eli Zaretskii @ 2024-02-08 13:36 ` Dmitry Gutov 2024-02-08 13:52 ` Eli Zaretskii 2024-02-08 13:41 ` Dmitry Gutov 2024-02-08 13:51 ` Rebinding Fn [Re: discoverability, better defaults and which-key in Emacs] Alan Mackenzie 2 siblings, 1 reply; 78+ messages in thread From: Dmitry Gutov @ 2024-02-08 13:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: visuweshm, justin, philipk, luangruo, jb, emacs-devel On 08/02/2024 15:02, Eli Zaretskii wrote: >> Date: Thu, 8 Feb 2024 14:18:34 +0200 >> Cc: justin@burkett.cc, philipk@posteo.net, luangruo@yahoo.com, >> jb@jeremybryant.net, emacs-devel@gnu.org >> From: Dmitry Gutov <dmitry@gutov.dev> >> >> On 08/02/2024 08:59, Eli Zaretskii wrote: >>> But >>> I added F1 to that text, which should help if someone did change >>> help-char. >> >> Whether help-char is changed, or 'C-h' is rebound anyway, can all be >> detected at runtime. <f1> can also have a different binding in the >> current prefix map--then the new message would be doubly incorrect. > > How frequently do people rebind F1? IME, never. Sure, likewise with C-h. That's why the original patch was probably okay as-is. > But I don't object to adding runtime detection of the help keys. Good. >> I'd rather we picked one (preferably correct) suggestion and printed that. > > Most people will never rebind C-h. Those who do could rebind it to a > character that cannot be used in this situation because it is already > bound in various prefix maps. Having two alternatives there increases > the probability that one of them will work. If we consider the situations where C-h or f1 is rebound, having misleading text in the message (with bindings that don't work) should concern us as well. Even if one of the suggestions is likely to work anyway (while the other doesn't). >> For context: I customize echo-keystrokes to a very low value and >> currently see this help message quite often. > > If the message annoys you, you can disable it. Sure - this is not a deal-breaker. But the more features I disable the less problems I could find while dogfooding. Until now I've been running with it, and it seemed unobtrusive enough. Runtime detection might even make it occasionally helpful in odd contexts where something shadows the binding. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-08 13:36 ` Dmitry Gutov @ 2024-02-08 13:52 ` Eli Zaretskii 2024-02-08 14:43 ` Dmitry Gutov 0 siblings, 1 reply; 78+ messages in thread From: Eli Zaretskii @ 2024-02-08 13:52 UTC (permalink / raw) To: Dmitry Gutov; +Cc: visuweshm, justin, philipk, luangruo, jb, emacs-devel > Date: Thu, 8 Feb 2024 15:36:43 +0200 > Cc: visuweshm@gmail.com, justin@burkett.cc, philipk@posteo.net, > luangruo@yahoo.com, jb@jeremybryant.net, emacs-devel@gnu.org > From: Dmitry Gutov <dmitry@gutov.dev> > > > How frequently do people rebind F1? IME, never. > > Sure, likewise with C-h. No, C-h is different. At least in the past some people wanted it to do the same as Backspace (we even have a special mode for that contingency). But F1 was a relatively late addition to Emacs, from when people were accustomed to have it invoke some help function, and no application I'm aware of has it bound to something else, unlike some other Fn keys. So I'm quite surprised to hear your "sure" above. Did you actually see that in the wild? > > Most people will never rebind C-h. Those who do could rebind it to a > > character that cannot be used in this situation because it is already > > bound in various prefix maps. Having two alternatives there increases > > the probability that one of them will work. > > If we consider the situations where C-h or f1 is rebound, having > misleading text in the message (with bindings that don't work) should > concern us as well. Even if one of the suggestions is likely to work > anyway (while the other doesn't). If you can come up with a code that detects at run time that help-key and/or F1 was rebound to a key that will not invoke describe-prefix-bindings, such a key should indeed better be removed from the message. But can we reliably do that? If we cannot, having two keys there instead of one is better. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-08 13:52 ` Eli Zaretskii @ 2024-02-08 14:43 ` Dmitry Gutov 2024-02-08 16:12 ` Dmitry Gutov 2024-02-08 16:50 ` Eli Zaretskii 0 siblings, 2 replies; 78+ messages in thread From: Dmitry Gutov @ 2024-02-08 14:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: visuweshm, justin, philipk, luangruo, jb, emacs-devel On 08/02/2024 15:52, Eli Zaretskii wrote: >> Date: Thu, 8 Feb 2024 15:36:43 +0200 >> Cc:visuweshm@gmail.com,justin@burkett.cc,philipk@posteo.net, >> luangruo@yahoo.com,jb@jeremybryant.net,emacs-devel@gnu.org >> From: Dmitry Gutov<dmitry@gutov.dev> >> >>> How frequently do people rebind F1? IME, never. >> Sure, likewise with C-h. > No, C-h is different. At least in the past some people wanted it to > do the same as Backspace (we even have a special mode for that > contingency). But F1 was a relatively late addition to Emacs, from > when people were accustomed to have it invoke some help function, and > no application I'm aware of has it bound to something else, unlike > some other Fn keys. So I'm quite surprised to hear your "sure" above. > Did you actually see that in the wild? I have seen neither exactly, but as a data point I can say that sometime until 2014 company-mode used <f1> as a binding in company-active-map. Not in a prefix map (so this is not an exact match), but still in a way that prevents help commands such as '<f1> v' from working. Later we added 'C-h' for the same binding (because "<f1> is extremely touch-typing unfriendly"), but as I'm looking at it now, the <f1> binding is still there. >>> Most people will never rebind C-h. Those who do could rebind it to a >>> character that cannot be used in this situation because it is already >>> bound in various prefix maps. Having two alternatives there increases >>> the probability that one of them will work. >> If we consider the situations where C-h or f1 is rebound, having >> misleading text in the message (with bindings that don't work) should >> concern us as well. Even if one of the suggestions is likely to work >> anyway (while the other doesn't). > If you can come up with a code that detects at run time that help-key > and/or F1 was rebound to a key that will not invoke > describe-prefix-bindings, such a key should indeed better be removed > from the message. But can we reliably do that? If we cannot, having > two keys there instead of one is better. I think we should be able to, but since help-key doesn't call any command directly through a map or fallback binding of some sort (instead it's dispatched ad-hoc), the solution I have tried so far (also using substitute-command-keys) did not help. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-08 14:43 ` Dmitry Gutov @ 2024-02-08 16:12 ` Dmitry Gutov 2024-02-11 2:17 ` Dmitry Gutov 2024-02-08 16:50 ` Eli Zaretskii 1 sibling, 1 reply; 78+ messages in thread From: Dmitry Gutov @ 2024-02-08 16:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: visuweshm, justin, philipk, luangruo, jb, emacs-devel [-- Attachment #1: Type: text/plain, Size: 888 bytes --] On 08/02/2024 16:43, Dmitry Gutov wrote: > If you can come up with a code that detects at run time that help-key > and/or F1 was rebound to a key that will not invoke > describe-prefix-bindings, such a key should indeed better be removed > from the message. But can we reliably do that? If we cannot, having > two keys there instead of one is better. Here's a rough draft. It seems to work in the basic cases that I've tried (changing help-char to something with a binding and rebinding <f1>), but doesn't account for key translations for far (e.g. if help-char is ?X and the prefix map has ?x, this isn't caught). Also, piping the current used map through so many methods is pretty messy, I'm sure whether I've used the appropriate value in other callsites of echo_now and echo_dash. There's also echo_update... So if anybody has something simpler in mind that'd be welcome. [-- Attachment #2: echo_keystrokes_help_v3.diff --] [-- Type: text/x-patch, Size: 5133 bytes --] diff --git a/lisp/help.el b/lisp/help.el index 72a4f8a800d..4a93e1cd915 100644 --- a/lisp/help.el +++ b/lisp/help.el @@ -2253,6 +2253,22 @@ help-form-show (with-output-to-temp-buffer " *Char Help*" (princ msg))))) +(defun help--append-suffix (str map) + (catch 'res + (dolist (val help-event-list) + (let ((key (vector (if (eql val 'help) + help-char + val)))) + (unless (and map (lookup-key map key)) + (throw 'res + (concat + str + (substitute-command-keys + (format + " (\\`%s' for help)" + (key-description key)))))))) + str)) + \f (defun help--docstring-quote (string) "Return a doc string that represents STRING. diff --git a/src/keyboard.c b/src/keyboard.c index 10cdef67348..8467b48c266 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -335,7 +335,7 @@ #define GROW_RAW_KEYBUF \ static void recursive_edit_unwind (Lisp_Object buffer); static Lisp_Object command_loop (void); -static void echo_now (void); +static void echo_now (Lisp_Object map); static ptrdiff_t echo_length (void); static void safe_run_hooks_maybe_narrowed (Lisp_Object, struct window *); @@ -553,7 +553,7 @@ echo_add_key (Lisp_Object c) character. */ static void -echo_dash (void) +echo_dash (Lisp_Object map) { /* Do nothing if not echoing at all. */ if (NILP (KVAR (current_kboard, echo_string))) @@ -595,15 +595,14 @@ echo_dash (void) if (echo_keystrokes_help) { - Lisp_Object help; - - help = build_string (" (\\`C-h' or \\`<f1>' for help)"); - kset_echo_string (current_kboard, - concat2 (KVAR (current_kboard, echo_string), - calln (Qsubstitute_command_keys, help))); + kset_echo_string (current_kboard, + CALLN (Ffuncall, + intern_c_string ("help--append-suffix"), + KVAR (current_kboard, echo_string), + map)); } - echo_now (); + echo_now (map); } static void @@ -629,7 +628,7 @@ echo_update (void) echo_add_key (c); } - echo_now (); + echo_now (Qnil); } } @@ -637,7 +636,7 @@ echo_update (void) doing so. */ static void -echo_now (void) +echo_now (Lisp_Object map) { if (!current_kboard->immediate_echo /* This test breaks calls that use `echo_now' to display the echo_prompt. @@ -646,7 +645,7 @@ echo_now (void) current_kboard->immediate_echo = true; echo_update (); /* Put a dash at the end to invite the user to type more. */ - echo_dash (); + echo_dash (map); } echoing = true; @@ -1597,7 +1596,7 @@ command_loop_1 (void) { current_kboard->immediate_echo = false; /* Refresh the echo message. */ - echo_now (); + echo_now (Qnil); } else cancel_echoing (); @@ -2739,7 +2738,7 @@ read_char (int commandflag, Lisp_Object map, || ok_to_echo_at_next_pause == NULL)) cancel_echoing (); else - echo_dash (); + echo_dash (map); /* Try reading a character via menu prompting in the minibuf. Try this before the sit-for, because the sit-for @@ -2846,7 +2845,7 @@ read_char (int commandflag, Lisp_Object map, This is because we are probably about to display a menu, and we don't want to delay before doing so. */ if (EVENT_HAS_PARAMETERS (prev_event)) - echo_now (); + echo_now (map); else { Lisp_Object tem0; @@ -2859,7 +2858,7 @@ read_char (int commandflag, Lisp_Object map, unbind_to (count, Qnil); if (EQ (tem0, Qt) && ! CONSP (Vunread_command_events)) - echo_now (); + echo_now (map); } } @@ -3263,7 +3262,7 @@ read_char (int commandflag, Lisp_Object map, kset_echo_string (current_kboard, saved_echo_string); kset_echo_prompt (current_kboard, saved_echo_prompt); if (saved_immediate_echo) - echo_now (); + echo_now (map); /* The input method can return no events. */ if (! CONSP (tem)) @@ -10490,7 +10489,7 @@ read_key_sequence (Lisp_Object *keybuf, Lisp_Object prompt, since it forces us to fiddle with current_kboard->immediate_echo before and after. */ current_kboard->immediate_echo = false; - echo_now (); + echo_now (Qnil); if (!echo_keystrokes_p ()) current_kboard->immediate_echo = false; } @@ -10499,7 +10498,7 @@ read_key_sequence (Lisp_Object *keybuf, Lisp_Object prompt, && echo_keystrokes_p ()) /* This doesn't put in a dash if the echo buffer is empty, so you don't always see a dash hanging out in the minibuffer. */ - echo_dash (); + echo_dash (Qnil); } /* Record the initial state of the echo area and this_command_keys; @@ -10695,7 +10694,7 @@ read_key_sequence (Lisp_Object *keybuf, Lisp_Object prompt, /* Set immediate_echo to false so as to force echo_now to redisplay (it will set immediate_echo right back to true). */ current_kboard->immediate_echo = false; - echo_now (); + echo_now (Qnil); } used_mouse_menu = used_mouse_menu_history[t]; } ^ permalink raw reply related [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-08 16:12 ` Dmitry Gutov @ 2024-02-11 2:17 ` Dmitry Gutov 2024-02-11 2:39 ` Po Lu 2024-02-11 6:49 ` Eli Zaretskii 0 siblings, 2 replies; 78+ messages in thread From: Dmitry Gutov @ 2024-02-11 2:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: visuweshm, justin, philipk, luangruo, jb, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1152 bytes --] On 08/02/2024 18:12, Dmitry Gutov wrote: > On 08/02/2024 16:43, Dmitry Gutov wrote: >> If you can come up with a code that detects at run time that help-key >> and/or F1 was rebound to a key that will not invoke >> describe-prefix-bindings, such a key should indeed better be removed >> from the message. But can we reliably do that? If we cannot, having >> two keys there instead of one is better. > > Here's a rough draft. > > It seems to work in the basic cases that I've tried (changing help-char > to something with a binding and rebinding <f1>), but doesn't account for > key translations for far (e.g. if help-char is ?X and the prefix map has > ?x, this isn't caught). > > Also, piping the current used map through so many methods is pretty > messy, I'm sure whether I've used the appropriate value in other > callsites of echo_now and echo_dash. There's also echo_update... > > So if anybody has something simpler in mind that'd be welcome. Here's that simpler version. It doesn't address the "key translations" example above, but it seems rare enough, and it should be possible to fix later. So I suggest we install this now. [-- Attachment #2: echo_keystrokes_help_v4.diff --] [-- Type: text/x-patch, Size: 1812 bytes --] diff --git a/lisp/help.el b/lisp/help.el index 72a4f8a800d..07eed2861c2 100644 --- a/lisp/help.el +++ b/lisp/help.el @@ -2253,6 +2253,27 @@ help-form-show (with-output-to-temp-buffer " *Char Help*" (princ msg))))) +(defun help--append-keystrokes-help (str) + (let* ((keys (this-single-command-keys)) + (bindings (delete nil + (mapcar (lambda (map) (lookup-key map keys t)) + (current-active-maps t))))) + (catch 'res + (dolist (val help-event-list) + (let ((key (vector (if (eql val 'help) + help-char + val)))) + (unless (seq-find (lambda (map) (and (keymapp map) (lookup-key map key))) + bindings) + (throw 'res + (concat + str + (substitute-command-keys + (format + " (\\`%s' for help)" + (key-description key)))))))) + str))) + \f (defun help--docstring-quote (string) "Return a doc string that represents STRING. diff --git a/src/keyboard.c b/src/keyboard.c index 10cdef67348..8cc1b2ec756 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -594,14 +594,9 @@ echo_dash (void) concat2 (KVAR (current_kboard, echo_string), dash)); if (echo_keystrokes_help) - { - Lisp_Object help; - - help = build_string (" (\\`C-h' or \\`<f1>' for help)"); - kset_echo_string (current_kboard, - concat2 (KVAR (current_kboard, echo_string), - calln (Qsubstitute_command_keys, help))); - } + kset_echo_string (current_kboard, + calln (intern_c_string ("help--append-keystrokes-help"), + KVAR (current_kboard, echo_string))); echo_now (); } ^ permalink raw reply related [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-11 2:17 ` Dmitry Gutov @ 2024-02-11 2:39 ` Po Lu 2024-02-11 12:30 ` Dmitry Gutov 2024-02-11 6:49 ` Eli Zaretskii 1 sibling, 1 reply; 78+ messages in thread From: Po Lu @ 2024-02-11 2:39 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Eli Zaretskii, visuweshm, justin, philipk, jb, emacs-devel Dmitry Gutov <dmitry@gutov.dev> writes: > diff --git a/src/keyboard.c b/src/keyboard.c > index 10cdef67348..8cc1b2ec756 100644 > --- a/src/keyboard.c > +++ b/src/keyboard.c > @@ -594,14 +594,9 @@ echo_dash (void) > concat2 (KVAR (current_kboard, echo_string), dash)); > > if (echo_keystrokes_help) > - { > - Lisp_Object help; > - > - help = build_string (" (\\`C-h' or \\`<f1>' for help)"); > - kset_echo_string (current_kboard, > - concat2 (KVAR (current_kboard, echo_string), > - calln (Qsubstitute_command_keys, help))); > - } > + kset_echo_string (current_kboard, > + calln (intern_c_string ("help--append-keystrokes-help"), > + KVAR (current_kboard, echo_string))); > > echo_now (); > } Please replace the call to intern_c_string with a DEFSYM. There's no good reason not to. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-11 2:39 ` Po Lu @ 2024-02-11 12:30 ` Dmitry Gutov 0 siblings, 0 replies; 78+ messages in thread From: Dmitry Gutov @ 2024-02-11 12:30 UTC (permalink / raw) To: Po Lu; +Cc: Eli Zaretskii, visuweshm, justin, philipk, jb, emacs-devel On 11/02/2024 04:39, Po Lu wrote: > Dmitry Gutov<dmitry@gutov.dev> writes: > >> diff --git a/src/keyboard.c b/src/keyboard.c >> index 10cdef67348..8cc1b2ec756 100644 >> --- a/src/keyboard.c >> +++ b/src/keyboard.c >> @@ -594,14 +594,9 @@ echo_dash (void) >> concat2 (KVAR (current_kboard, echo_string), dash)); >> >> if (echo_keystrokes_help) >> - { >> - Lisp_Object help; >> - >> - help = build_string (" (\\`C-h' or \\`<f1>' for help)"); >> - kset_echo_string (current_kboard, >> - concat2 (KVAR (current_kboard, echo_string), >> - calln (Qsubstitute_command_keys, help))); >> - } >> + kset_echo_string (current_kboard, >> + calln (intern_c_string ("help--append-keystrokes-help"), >> + KVAR (current_kboard, echo_string))); >> >> echo_now (); >> } > Please replace the call to intern_c_string with a DEFSYM. There's no > good reason not to. Thanks, I'll do that when committing. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-11 2:17 ` Dmitry Gutov 2024-02-11 2:39 ` Po Lu @ 2024-02-11 6:49 ` Eli Zaretskii 2024-02-11 12:26 ` Dmitry Gutov 1 sibling, 1 reply; 78+ messages in thread From: Eli Zaretskii @ 2024-02-11 6:49 UTC (permalink / raw) To: Dmitry Gutov; +Cc: visuweshm, justin, philipk, luangruo, jb, emacs-devel > Date: Sun, 11 Feb 2024 04:17:21 +0200 > From: Dmitry Gutov <dmitry@gutov.dev> > Cc: visuweshm@gmail.com, justin@burkett.cc, philipk@posteo.net, > luangruo@yahoo.com, jb@jeremybryant.net, emacs-devel@gnu.org > > Here's that simpler version. > > It doesn't address the "key translations" example above, but it seems > rare enough, and it should be possible to fix later. > > So I suggest we install this now. This basically throws away the addition of F1 I did, doesn't it? I added it for a reason, and I don't want to lose it. If you want to make sure F1 is bound to help-command, and omit it from the message if not, that is fine by me. But I object to omitting it unconditionally. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-11 6:49 ` Eli Zaretskii @ 2024-02-11 12:26 ` Dmitry Gutov 2024-02-11 15:00 ` Eli Zaretskii 0 siblings, 1 reply; 78+ messages in thread From: Dmitry Gutov @ 2024-02-11 12:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: visuweshm, justin, philipk, luangruo, jb, emacs-devel On 11/02/2024 08:49, Eli Zaretskii wrote: >> Date: Sun, 11 Feb 2024 04:17:21 +0200 >> From: Dmitry Gutov<dmitry@gutov.dev> >> Cc:visuweshm@gmail.com,justin@burkett.cc,philipk@posteo.net, >> luangruo@yahoo.com,jb@jeremybryant.net,emacs-devel@gnu.org >> >> Here's that simpler version. >> >> It doesn't address the "key translations" example above, but it seems >> rare enough, and it should be possible to fix later. >> >> So I suggest we install this now. > This basically throws away the addition of F1 I did, doesn't it? I > added it for a reason, and I don't want to lose it. If you want to > make sure F1 is bound to help-command, and omit it from the message if > not, that is fine by me. But I object to omitting it unconditionally. Not quite. <f1> is in help-event-list. This function iterates among the available options, and if it sees that help-char is bound in the current prefix map(s), it tries <f1>, and if that one is bound as well, the last remaining element, which is '?'. It also prints the value of help-char correctly if it was changed to a different value (if it's not bound in the current prefix map(s)). ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-11 12:26 ` Dmitry Gutov @ 2024-02-11 15:00 ` Eli Zaretskii 2024-02-11 20:36 ` Dmitry Gutov 0 siblings, 1 reply; 78+ messages in thread From: Eli Zaretskii @ 2024-02-11 15:00 UTC (permalink / raw) To: Dmitry Gutov; +Cc: visuweshm, justin, philipk, luangruo, jb, emacs-devel > Date: Sun, 11 Feb 2024 14:26:38 +0200 > Cc: visuweshm@gmail.com, justin@burkett.cc, philipk@posteo.net, > luangruo@yahoo.com, jb@jeremybryant.net, emacs-devel@gnu.org > From: Dmitry Gutov <dmitry@gutov.dev> > > >> So I suggest we install this now. > > This basically throws away the addition of F1 I did, doesn't it? I > > added it for a reason, and I don't want to lose it. If you want to > > make sure F1 is bound to help-command, and omit it from the message if > > not, that is fine by me. But I object to omitting it unconditionally. > > Not quite. <f1> is in help-event-list. > > This function iterates among the available options, and if it sees that > help-char is bound in the current prefix map(s), it tries <f1>, and if > that one is bound as well, the last remaining element, which is '?'. > > It also prints the value of help-char correctly if it was changed to a > different value (if it's not bound in the current prefix map(s)). OK, thanks. Then I have no objections. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-11 15:00 ` Eli Zaretskii @ 2024-02-11 20:36 ` Dmitry Gutov 0 siblings, 0 replies; 78+ messages in thread From: Dmitry Gutov @ 2024-02-11 20:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: visuweshm, justin, philipk, luangruo, jb, emacs-devel On 11/02/2024 17:00, Eli Zaretskii wrote: >> This function iterates among the available options, and if it sees that >> help-char is bound in the current prefix map(s), it tries <f1>, and if >> that one is bound as well, the last remaining element, which is '?'. >> >> It also prints the value of help-char correctly if it was changed to a >> different value (if it's not bound in the current prefix map(s)). > OK, thanks. Then I have no objections. Very good. Pushed to master. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-08 14:43 ` Dmitry Gutov 2024-02-08 16:12 ` Dmitry Gutov @ 2024-02-08 16:50 ` Eli Zaretskii 1 sibling, 0 replies; 78+ messages in thread From: Eli Zaretskii @ 2024-02-08 16:50 UTC (permalink / raw) To: Dmitry Gutov, Stefan Monnier Cc: visuweshm, justin, philipk, luangruo, jb, emacs-devel > Date: Thu, 8 Feb 2024 16:43:41 +0200 > Cc: visuweshm@gmail.com, justin@burkett.cc, philipk@posteo.net, > luangruo@yahoo.com, jb@jeremybryant.net, emacs-devel@gnu.org > From: Dmitry Gutov <dmitry@gutov.dev> > > >> If we consider the situations where C-h or f1 is rebound, having > >> misleading text in the message (with bindings that don't work) should > >> concern us as well. Even if one of the suggestions is likely to work > >> anyway (while the other doesn't). > > If you can come up with a code that detects at run time that help-key > > and/or F1 was rebound to a key that will not invoke > > describe-prefix-bindings, such a key should indeed better be removed > > from the message. But can we reliably do that? If we cannot, having > > two keys there instead of one is better. > > I think we should be able to, but since help-key doesn't call any > command directly through a map or fallback binding of some sort (instead > it's dispatched ad-hoc), the solution I have tried so far (also using > substitute-command-keys) did not help. Maybe Stefan (CC'ed) could have an idea. In general, since the key sequence was just echoed, we do know what sequence was typed, and can test whether adding help-char to it would produce a binding, like what we do in read_key_sequence where we decide whether to invoke prefix-help-command. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-08 13:02 ` Eli Zaretskii 2024-02-08 13:36 ` Dmitry Gutov @ 2024-02-08 13:41 ` Dmitry Gutov 2024-02-08 13:51 ` Rebinding Fn [Re: discoverability, better defaults and which-key in Emacs] Alan Mackenzie 2 siblings, 0 replies; 78+ messages in thread From: Dmitry Gutov @ 2024-02-08 13:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: visuweshm, justin, philipk, luangruo, jb, emacs-devel On 08/02/2024 15:02, Eli Zaretskii wrote: >> Date: Thu, 8 Feb 2024 14:18:34 +0200 >> Cc: justin@burkett.cc, philipk@posteo.net, luangruo@yahoo.com, >> jb@jeremybryant.net, emacs-devel@gnu.org >> From: Dmitry Gutov <dmitry@gutov.dev> >> >> On 08/02/2024 08:59, Eli Zaretskii wrote: >>> But >>> I added F1 to that text, which should help if someone did change >>> help-char. >> >> Whether help-char is changed, or 'C-h' is rebound anyway, can all be >> detected at runtime. <f1> can also have a different binding in the >> current prefix map--then the new message would be doubly incorrect. > > How frequently do people rebind F1? IME, never. Sure, likewise with C-h. That's why the original patch was probably okay as-is. > But I don't object to adding runtime detection of the help keys. Good. >> I'd rather we picked one (preferably correct) suggestion and printed that. > > Most people will never rebind C-h. Those who do could rebind it to a > character that cannot be used in this situation because it is already > bound in various prefix maps. Having two alternatives there increases > the probability that one of them will work. If we consider the situations where C-h or f1 is rebound, having misleading text in the message (with bindings that don't work) should concern us as well. Even if one of the suggestions is likely to work anyway (while the other doesn't). >> For context: I customize echo-keystrokes to a very low value and >> currently see this help message quite often. > > If the message annoys you, you can disable it. Sure - this is not a deal-breaker. But the more features I disable the less problems I could find while dogfooding. Until now I've been running with it, and it seemed unobtrusive enough. Runtime detection might even make it occasionally helpful in odd contexts where something shadows the binding. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Rebinding Fn [Re: discoverability, better defaults and which-key in Emacs] 2024-02-08 13:02 ` Eli Zaretskii 2024-02-08 13:36 ` Dmitry Gutov 2024-02-08 13:41 ` Dmitry Gutov @ 2024-02-08 13:51 ` Alan Mackenzie 2024-02-08 13:55 ` Eli Zaretskii 2 siblings, 1 reply; 78+ messages in thread From: Alan Mackenzie @ 2024-02-08 13:51 UTC (permalink / raw) To: Eli Zaretskii Cc: Dmitry Gutov, visuweshm, justin, philipk, luangruo, jb, emacs-devel Hello, Eli. On Thu, Feb 08, 2024 at 15:02:50 +0200, Eli Zaretskii wrote: > > Date: Thu, 8 Feb 2024 14:18:34 +0200 > > Cc: justin@burkett.cc, philipk@posteo.net, luangruo@yahoo.com, > > jb@jeremybryant.net, emacs-devel@gnu.org > > From: Dmitry Gutov <dmitry@gutov.dev> > > On 08/02/2024 08:59, Eli Zaretskii wrote: > > > But > > > I added F1 to that text, which should help if someone did change > > > help-char. > > Whether help-char is changed, or 'C-h' is rebound anyway, can all be > > detected at runtime. <f1> can also have a different binding in the > > current prefix map--then the new message would be doubly incorrect. > How frequently do people rebind F1? IME, never. I bind F1 all the time, in the global map, and have done for over 20 years. It selects the first created frame (which happens to be conveniently called "F1" on a tty). Likewise for F2 to F11. Standard Emacs is strangely deficient in keyboard commands to select frames. C-x 5 o is unusably cumbersome if there are more than two or three frames. [ .... ] -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Rebinding Fn [Re: discoverability, better defaults and which-key in Emacs] 2024-02-08 13:51 ` Rebinding Fn [Re: discoverability, better defaults and which-key in Emacs] Alan Mackenzie @ 2024-02-08 13:55 ` Eli Zaretskii 2024-02-08 14:04 ` Alan Mackenzie 0 siblings, 1 reply; 78+ messages in thread From: Eli Zaretskii @ 2024-02-08 13:55 UTC (permalink / raw) To: Alan Mackenzie Cc: dmitry, visuweshm, justin, philipk, luangruo, jb, emacs-devel > Date: Thu, 8 Feb 2024 13:51:21 +0000 > Cc: Dmitry Gutov <dmitry@gutov.dev>, visuweshm@gmail.com, justin@burkett.cc, > philipk@posteo.net, luangruo@yahoo.com, jb@jeremybryant.net, > emacs-devel@gnu.org > From: Alan Mackenzie <acm@muc.de> > > > How frequently do people rebind F1? IME, never. > > I bind F1 all the time And you need the help advice Dmitry added? ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Rebinding Fn [Re: discoverability, better defaults and which-key in Emacs] 2024-02-08 13:55 ` Eli Zaretskii @ 2024-02-08 14:04 ` Alan Mackenzie 0 siblings, 0 replies; 78+ messages in thread From: Alan Mackenzie @ 2024-02-08 14:04 UTC (permalink / raw) To: Eli Zaretskii Cc: dmitry, visuweshm, justin, philipk, luangruo, jb, emacs-devel Hello, Eli. On Thu, Feb 08, 2024 at 15:55:36 +0200, Eli Zaretskii wrote: > > Date: Thu, 8 Feb 2024 13:51:21 +0000 > > Cc: Dmitry Gutov <dmitry@gutov.dev>, visuweshm@gmail.com, justin@burkett.cc, > > philipk@posteo.net, luangruo@yahoo.com, jb@jeremybryant.net, > > emacs-devel@gnu.org > > From: Alan Mackenzie <acm@muc.de> > > > How frequently do people rebind F1? IME, never. > > I bind F1 all the time > And you need the help advice Dmitry added? No, of course not. I just felt I needed to add a correction. It is perhaps unwise to suggest that something doable in Emacs hasn't been done. Somebody, somewhere, _will_ have done it. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-07 18:31 ` Dmitry Gutov 2024-02-07 19:13 ` Eli Zaretskii 2024-02-08 1:46 ` Visuwesh @ 2024-02-08 13:25 ` Po Lu 2024-02-08 13:27 ` Dmitry Gutov 2 siblings, 1 reply; 78+ messages in thread From: Po Lu @ 2024-02-08 13:25 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Eli Zaretskii, justin, philipk, jb, emacs-devel Dmitry Gutov <dmitry@gutov.dev> writes: > + if (echo_keystrokes_help) > + { > + AUTO_STRING (help, " (\\`C-h' for help)"); > + kset_echo_string (current_kboard, > + concat2 (KVAR (current_kboard, echo_string), > + calln (Qsubstitute_command_keys, help))); > + } Just for the record, calling functions defined in Lisp with automatic variables as arguments will give rise to mysterious crashes down the line. Strings constructed by AUTO_STRING must never be returned, provided to Lisp, or referenced after moving out of scope, as its name suggests. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-08 13:25 ` discoverability, better defaults and which-key in Emacs Po Lu @ 2024-02-08 13:27 ` Dmitry Gutov 2024-02-08 13:36 ` Dmitry Gutov 0 siblings, 1 reply; 78+ messages in thread From: Dmitry Gutov @ 2024-02-08 13:27 UTC (permalink / raw) To: Po Lu; +Cc: Eli Zaretskii, justin, philipk, jb, emacs-devel On 08/02/2024 15:25, Po Lu wrote: > Dmitry Gutov<dmitry@gutov.dev> writes: > >> + if (echo_keystrokes_help) >> + { >> + AUTO_STRING (help, " (\\`C-h' for help)"); >> + kset_echo_string (current_kboard, >> + concat2 (KVAR (current_kboard, echo_string), >> + calln (Qsubstitute_command_keys, help))); >> + } > Just for the record, calling functions defined in Lisp with automatic > variables as arguments will give rise to mysterious crashes down the > line. Strings constructed by AUTO_STRING must never be returned, > provided to Lisp, or referenced after moving out of scope, as its name > suggests. It was used with 'concat' here to construct a new string. Is that still a problem? ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-08 13:27 ` Dmitry Gutov @ 2024-02-08 13:36 ` Dmitry Gutov 0 siblings, 0 replies; 78+ messages in thread From: Dmitry Gutov @ 2024-02-08 13:36 UTC (permalink / raw) To: Po Lu; +Cc: Eli Zaretskii, justin, philipk, jb, emacs-devel On 08/02/2024 15:27, Dmitry Gutov wrote: > On 08/02/2024 15:25, Po Lu wrote: >> Dmitry Gutov<dmitry@gutov.dev> writes: >> >>> + if (echo_keystrokes_help) >>> + { >>> + AUTO_STRING (help, " (\\`C-h' for help)"); >>> + kset_echo_string (current_kboard, >>> + concat2 (KVAR (current_kboard, echo_string), >>> + calln (Qsubstitute_command_keys, help))); >>> + } >> Just for the record, calling functions defined in Lisp with automatic >> variables as arguments will give rise to mysterious crashes down the >> line. Strings constructed by AUTO_STRING must never be returned, >> provided to Lisp, or referenced after moving out of scope, as its name >> suggests. > > It was used with 'concat' here to construct a new string. > > Is that still a problem? Ah, I passed it to Lisp function first. Gotcha. Thanks. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-01-31 23:23 discoverability, better defaults and which-key in Emacs Jeremy Bryant 2024-02-01 2:45 ` Po Lu @ 2024-02-01 7:35 ` Eli Zaretskii 2024-02-01 21:16 ` Jeremy Bryant ` (2 more replies) 1 sibling, 3 replies; 78+ messages in thread From: Eli Zaretskii @ 2024-02-01 7:35 UTC (permalink / raw) To: Jeremy Bryant; +Cc: justin, emacs-devel > From: Jeremy Bryant <jb@jeremybryant.net> > Date: Wed, 31 Jan 2024 23:23:29 +0000 > > A recent theme of discussion has been improving discoverability of Emacs > features, and in a related way, 'better defaults'. > > Here is a suggestion - include which-key in core and potentially enable > by for new users. How do we detect "new users"? If we include which-key, but do not enable it by default, would that be good enough? Another idea is to add a feature whereby, after some delay after the user types an incomplete key sequence, the buffer usually popped by C-h or '?' pops up automatically. This would be a smaller change in the UX, which might therefore be more easily acceptable even by not-so-new users. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-01 7:35 ` Eli Zaretskii @ 2024-02-01 21:16 ` Jeremy Bryant 2024-02-02 6:43 ` Eli Zaretskii 2024-02-01 21:17 ` orzodk 2024-02-02 16:00 ` Howard Melman 2 siblings, 1 reply; 78+ messages in thread From: Jeremy Bryant @ 2024-02-01 21:16 UTC (permalink / raw) To: Eli Zaretskii; +Cc: justin, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Jeremy Bryant <jb@jeremybryant.net> >> Date: Wed, 31 Jan 2024 23:23:29 +0000 >> >> A recent theme of discussion has been improving discoverability of Emacs >> features, and in a related way, 'better defaults'. >> >> Here is a suggestion - include which-key in core and potentially enable >> by for new users. > > How do we detect "new users"? Good question, how about a user entry on the splashscreen? > If we include which-key, but do not enable it by default, would that > be good enough? Yes. How can I help with this? Move the .el files from the ELPA package into lisp/ ? Manual entry- ? > > Another idea is to add a feature whereby, after some delay after the > user types an incomplete key sequence, the buffer usually popped by > C-h or '?' pops up automatically. This would be a smaller change in > the UX, which might therefore be more easily acceptable even by > not-so-new users. Interesting, which buffer and part of the code is this? (it seems to appear in *Help*) ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-01 21:16 ` Jeremy Bryant @ 2024-02-02 6:43 ` Eli Zaretskii 2024-02-02 7:00 ` Emanuel Berg ` (2 more replies) 0 siblings, 3 replies; 78+ messages in thread From: Eli Zaretskii @ 2024-02-02 6:43 UTC (permalink / raw) To: Jeremy Bryant; +Cc: justin, emacs-devel > From: Jeremy Bryant <jb@jeremybryant.net> > Cc: justin@burkett.cc, emacs-devel@gnu.org > Date: Thu, 01 Feb 2024 21:16:43 +0000 > > >> Here is a suggestion - include which-key in core and potentially enable > >> by for new users. > > > > How do we detect "new users"? > > Good question, how about a user entry on the splashscreen? I don't think I understand, please elaborate. Do you mean we will ask users to say, up front, that they consider themselves "new users", each time they start a new Emacs session? > > If we include which-key, but do not enable it by default, would that > > be good enough? > > Yes. > How can I help with this? > > Move the .el files from the ELPA package into lisp/ ? > Manual entry- ? Something like that. Philip and Stefan will be able to describe the details. > > Another idea is to add a feature whereby, after some delay after the > > user types an incomplete key sequence, the buffer usually popped by > > C-h or '?' pops up automatically. This would be a smaller change in > > the UX, which might therefore be more easily acceptable even by > > not-so-new users. > > Interesting, which buffer and part of the code is this? > (it seems to appear in *Help*) Yes, it appears in *Help*, and is produced by describe-prefix-bindings (via prefix-help-command). ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-02 6:43 ` Eli Zaretskii @ 2024-02-02 7:00 ` Emanuel Berg 2024-02-02 7:43 ` Eli Zaretskii 2024-02-03 11:30 ` Jeremy Bryant 2024-02-03 11:36 ` Moving which-key ELPA package into core - " Jeremy Bryant 2 siblings, 1 reply; 78+ messages in thread From: Emanuel Berg @ 2024-02-02 7:00 UTC (permalink / raw) To: emacs-devel Eli Zaretskii wrote: >>>> Here is a suggestion - include which-key in core and >>>> potentially enable by for new users. >>> >>> How do we detect "new users"? >> >> Good question, how about a user entry on the splashscreen? > > I don't think I understand, please elaborate. Do you mean we > will ask users to say, up front, that they consider > themselves "new users", each time they start a new > Emacs session? Instead of Emacs finding out who is a new user or old, new and old users alike should find what they look for in Emacs. With configuration, maybe one can have a FAQ specifically for that. If one has the 20 most common configuration use cases listed with Elisp one-liners to do it, that would be a good start. And beyond that, people already have experience anyway. Another case is finding code in core Emacs and in ELPA to do stuff so one don't spend time writing Elisp for that oneself. This is an area where I failed big time myself. Maybe today googling can offer more as much more code is available online? Probably someone is working on an AI tool as we speak, so that one can truly "ask Emacs". I for one would be very interested to know what of my Elisp I can discard in favor of using stuff in core Emacs. But I don't have a confident answer how to find out. -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-02 7:00 ` Emanuel Berg @ 2024-02-02 7:43 ` Eli Zaretskii 2024-02-02 15:25 ` [External] : " Drew Adams 2024-02-03 11:39 ` Jeremy Bryant 0 siblings, 2 replies; 78+ messages in thread From: Eli Zaretskii @ 2024-02-02 7:43 UTC (permalink / raw) To: Emanuel Berg; +Cc: emacs-devel > From: Emanuel Berg <incal@dataswamp.org> > Date: Fri, 02 Feb 2024 08:00:22 +0100 > > Instead of Emacs finding out who is a new user or old, new and > old users alike should find what they look for in Emacs. > > With configuration, maybe one can have a FAQ specifically for > that. If one has the 20 most common configuration use cases > listed with Elisp one-liners to do it, that would be a good > start. And beyond that, people already have experience anyway. This idea came up several times here, and was met with a general agreement, but no one stepped forward to work on those "most common configurations". And it is not easy to do, since the configurations depend on the needs of the user (whether the user is a programmer and in what language(s), what other tasks and jobs does the user want to accomplish in Emacs -- email, todo items, etc.) and also some general user preferences (mouse vs keyboard etc.). Patches welcome, of course. > Another case is finding code in core Emacs and in ELPA to do > stuff so one don't spend time writing Elisp for that oneself. > This is an area where I failed big time myself. Maybe today > googling can offer more as much more code is available online? The Emacs apropos commands, if used wisely, should help you. You might find that some of our documentation needs to be enhanced to make discoverability easier, in which case please report the deficiencies, so we could make this better. > I for one would be very interested to know what of my Elisp > I can discard in favor of using stuff in core Emacs. > But I don't have a confident answer how to find out. Some Emacs commands I suggest for this are: C-u M-x apropos M-x apropos-documentation C-h R elisp RET followed by 'i' (Info-index) and the subject ^ permalink raw reply [flat|nested] 78+ messages in thread
* RE: [External] : Re: discoverability, better defaults and which-key in Emacs 2024-02-02 7:43 ` Eli Zaretskii @ 2024-02-02 15:25 ` Drew Adams 2024-02-02 15:53 ` Emanuel Berg ` (2 more replies) 2024-02-03 11:39 ` Jeremy Bryant 1 sibling, 3 replies; 78+ messages in thread From: Drew Adams @ 2024-02-02 15:25 UTC (permalink / raw) To: Eli Zaretskii, Emanuel Berg; +Cc: emacs-devel@gnu.org > > Another case is finding code in core Emacs and in ELPA to do > > stuff so one don't spend time writing Elisp for that oneself. > > This is an area where I failed big time myself. Maybe today > > googling can offer more as much more code is available online? > > The Emacs apropos commands, if used wisely, should help you. You > might find that some of our documentation needs to be enhanced to make > discoverability easier, in which case please report the deficiencies, > so we could make this better. > > > I for one would be very interested to know what of my Elisp > > I can discard in favor of using stuff in core Emacs. > > But I don't have a confident answer how to find out. > > Some Emacs commands I suggest for this are: > C-u M-x apropos > M-x apropos-documentation > C-h R elisp RET followed by 'i' (Info-index) and the subject +1 to all of that. ___ The most important aid for users - esp. but not only new users - is IMHO for them to learn how to better "ask Emacs". Emacs provides lots of ways to discover and find things, from the most common or superficial things (help keys, menus) to those deepest in its belly (Lisp, C). That fact isn't obvious to new users, and even old users can benefit from being reminded of it. Learning better how to ask Emacs is always possible, regardless of level of familiarity or years of use. ___ Every top-level, superficially obvious point of entry could help pass the message to a user to help yourself by learning better how to "ask Emacs". Top-level entry points can include toolbar, menu-bar Help menu, splash screen, `C-h t' tutorial,... ___ [ Maybe even every *Help* buffer could have a link (the same one-line link) to a manual entry or to some other presentation of info about asking Emacs (i.e., finding things). Perhaps with an added boost from AI-thingies, such a link could be *Help*-context sensitive. And perhaps (with AI) some actions that users take could (optionally) sometimes be followed by a popup tip about a handy (maybe quicker) way to ask Emacs about something they seem to be looking for or not be aware of. ] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [External] : Re: discoverability, better defaults and which-key in Emacs 2024-02-02 15:25 ` [External] : " Drew Adams @ 2024-02-02 15:53 ` Emanuel Berg 2024-02-02 16:04 ` Emanuel Berg 2024-02-03 11:46 ` Jeremy Bryant 2 siblings, 0 replies; 78+ messages in thread From: Emanuel Berg @ 2024-02-02 15:53 UTC (permalink / raw) To: emacs-devel Drew Adams wrote: >>> I for one would be very interested to know what of my >>> Elisp I can discard in favor of using stuff in core Emacs. >>> But I don't have a confident answer how to find out. >> >> Some Emacs commands I suggest for this are: >> C-u M-x apropos >> M-x apropos-documentation >> C-h R elisp RET followed by 'i' (Info-index) and the subject > > +1 to all of that. > > The most important aid for users - esp. but not only new > users - is IMHO for them to learn how to better "ask Emacs". If sorted alphabetically, this is my first Elisp file, abc.el. After that, the second file, align-from-left.el. How do I ask Emacs if someone already wrote it and made it available? I think part of the problem is before one has programmed it, it is very difficult to formulate it in an exact way, and one doesn't always have a clear image what one is doing, even. I'm not challenging anyone to ask Emacs, rather ... they are two examples what stuff I have been writing and many, many times wondered how anyone would ever know, what everyone else are writing. Someone else must have already written it, right? Interestingly, it is often easier to find advanced, specialized stuff than small math and data manipulation functions. Since they are so general, if one searches, one gets a lot of hits, a lot of them doing something quite similar but not exactly the same. Maybe someone already tried to have Lisp with standard libraries. Several times? ;;; -*- lexical-binding: t -*- ;; ;; this file: ;; https://dataswamp.org/~incal/emacs-init/abc.el (require 'cl-lib) (defun alphabet (&optional as-list) (let ((abc "a b c d e f g h i j k l m n o p q r s t u v w x y z")) (if as-list (cl-remove ?\s (string-to-list abc)) abc) )) ;; (alphabet) ; a b c d e f g h i j k l m n o p q r s t u v w x y z ;; (alphabet t) ; (97 98 99 100 101 102 103 104 105 106 107 108 ...) (defun echo-alphabet (&optional num) (interactive "P") (or num (setq num (length (alphabet t)))) (let*((part (cl-subseq (alphabet t) 0 num)) (str-list (mapcar (lambda (c) (char-to-string c)) part)) (str-almost (format "%s" str-list)) (str (substring str-almost 1 (1- (length str-almost)))) ) (message str) )) (defalias 'abc #'echo-alphabet) ;; (echo-alphabet) ; a b c d e f g h i j k l m n o p q r s t u v w x y z ;; (echo-alphabet 2) ; a b ;; (echo-alphabet -2) ; a b c d e f g h i j k l m n o p q r s t u v w x ;; (echo-alphabet 10) ; a b c d e f g h i j ;; (echo-alphabet -10) ; a b c d e f g h i j k l m n o p (provide 'abc) ;;; -*- lexical-binding: t -*- ;; ;; this file: ;; https://dataswamp.org/~incal/emacs-init/align-from-left.el (require 'cl-lib) (let ((alf-regexp)) (defun align-from-left (&optional set-regexp) (interactive "p") (let ((default-regexp "^\\|[[:punct:]]\\|[[:space:]][[:alnum:]]")) (unless (stringp set-regexp) (cl-case set-regexp ( 4 (setq alf-regexp (read-regexp "regexp: "))) (16 (setq alf-regexp default-regexp)) ( t (unless alf-regexp (setq alf-regexp default-regexp) ))))) (let ((beg (point)) (re (or (and (stringp set-regexp) set-regexp) alf-regexp) )) (when (re-search-backward re (line-beginning-position) t) (while (looking-at "[[:space:]]") (forward-char) ) (insert (make-string (- beg (point)) ?\s)) )))) (declare-function align-from-left nil) (provide 'align-from-left) -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [External] : Re: discoverability, better defaults and which-key in Emacs 2024-02-02 15:25 ` [External] : " Drew Adams 2024-02-02 15:53 ` Emanuel Berg @ 2024-02-02 16:04 ` Emanuel Berg 2024-02-03 11:46 ` Jeremy Bryant 2 siblings, 0 replies; 78+ messages in thread From: Emanuel Berg @ 2024-02-02 16:04 UTC (permalink / raw) To: emacs-devel Drew Adams wrote: > And perhaps (with AI) some actions that users take could > (optionally) sometimes be followed by a popup tip about > a handy (maybe quicker) way to ask Emacs about something > they seem to be looking for or not be aware of. One will document the individual pieces and they will be nodes in a huge AI-searchable network, so that everyone can polish their gems in peace and quiet, then AI will help newcomers navigate and integrate everything seamlessly :) One should feed the entire Emacs world, all Usenet groups, mailing lists, web forums and so on into an AI and train it on that. And of course the source and documentation and manual. And #emacs as well, the entire backlog. If the AI can figure out what is offtopic, jokes etc. -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [External] : Re: discoverability, better defaults and which-key in Emacs 2024-02-02 15:25 ` [External] : " Drew Adams 2024-02-02 15:53 ` Emanuel Berg 2024-02-02 16:04 ` Emanuel Berg @ 2024-02-03 11:46 ` Jeremy Bryant 2 siblings, 0 replies; 78+ messages in thread From: Jeremy Bryant @ 2024-02-03 11:46 UTC (permalink / raw) To: Drew Adams; +Cc: Eli Zaretskii, Emanuel Berg, emacs-devel > +1 to all of that. > ___ > > The most important aid for users - esp. but not > only new users - is IMHO for them to learn how > to better "ask Emacs". Emacs provides lots of > ways to discover and find things, from the most > common or superficial things (help keys, menus) > to those deepest in its belly (Lisp, C). > > That fact isn't obvious to new users, and even > old users can benefit from being reminded of it. > Learning better how to ask Emacs is always > possible, regardless of level of familiarity or > years of use. > ___ > > Every top-level, superficially obvious point of > entry could help pass the message to a user to > help yourself by learning better how to "ask > Emacs". Top-level entry points can include > toolbar, menu-bar Help menu, splash screen, > `C-h t' tutorial,... > ___ > > [ Maybe even every *Help* buffer could have a > link (the same one-line link) to a manual > entry or to some other presentation of info > about asking Emacs (i.e., finding things). > > Perhaps with an added boost from AI-thingies, > such a link could be *Help*-context sensitive. > > And perhaps (with AI) some actions that users > take could (optionally) sometimes be followed > by a popup tip about a handy (maybe quicker) > way to ask Emacs about something they seem to > be looking for or not be aware of. ] How about discoverability regular reminders being a user-option (called something like discoverability-help-buffer), available to new and veteran users alike? This would make the *Help* buffers bigger but with useful reminders such as C-h S info-lookup-symbol to jump to the manual etc, and can be turned off at will? ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-02 7:43 ` Eli Zaretskii 2024-02-02 15:25 ` [External] : " Drew Adams @ 2024-02-03 11:39 ` Jeremy Bryant 2024-02-03 12:12 ` Eli Zaretskii 1 sibling, 1 reply; 78+ messages in thread From: Jeremy Bryant @ 2024-02-03 11:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Emanuel Berg, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Emanuel Berg <incal@dataswamp.org> >> Date: Fri, 02 Feb 2024 08:00:22 +0100 >> >> Instead of Emacs finding out who is a new user or old, new and >> old users alike should find what they look for in Emacs. >> >> With configuration, maybe one can have a FAQ specifically for >> that. If one has the 20 most common configuration use cases >> listed with Elisp one-liners to do it, that would be a good >> start. And beyond that, people already have experience anyway. > > This idea came up several times here, and was met with a general > agreement, but no one stepped forward to work on those "most common > configurations". And it is not easy to do, since the configurations > depend on the needs of the user (whether the user is a programmer and > in what language(s), what other tasks and jobs does the user want to > accomplish in Emacs -- email, todo items, etc.) and also some general > user preferences (mouse vs keyboard etc.). > > Patches welcome, of course. Would it be useful to have a few 'starter' commented init files / configurations. This would be a built-in version of personal init files, but very small, and commented. I can work on such minimal configurations, would you suggest a patch somewhere specifically in the Emacs tree? I can work on a patch. >> Another case is finding code in core Emacs and in ELPA to do >> stuff so one don't spend time writing Elisp for that oneself. >> This is an area where I failed big time myself. Maybe today >> googling can offer more as much more code is available online? > > The Emacs apropos commands, if used wisely, should help you. You > might find that some of our documentation needs to be enhanced to make > discoverability easier, in which case please report the deficiencies, > so we could make this better. > >> I for one would be very interested to know what of my Elisp >> I can discard in favor of using stuff in core Emacs. >> But I don't have a confident answer how to find out. > > Some Emacs commands I suggest for this are: > > C-u M-x apropos > M-x apropos-documentation > C-h R elisp RET followed by 'i' (Info-index) and the subject Would it make sense to have a specific small section in the Emacs manual that Then a link to that manual section could be provided early on A sort of 'discoverability start point'? I can work on a manual patch if you think this would be a good place for it? ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-03 11:39 ` Jeremy Bryant @ 2024-02-03 12:12 ` Eli Zaretskii 2024-02-03 14:07 ` Jeremy Bryant 0 siblings, 1 reply; 78+ messages in thread From: Eli Zaretskii @ 2024-02-03 12:12 UTC (permalink / raw) To: Jeremy Bryant; +Cc: incal, emacs-devel > From: Jeremy Bryant <jb@jeremybryant.net> > Cc: Emanuel Berg <incal@dataswamp.org>, emacs-devel@gnu.org > Date: Sat, 03 Feb 2024 11:39:50 +0000 > > > Eli Zaretskii <eliz@gnu.org> writes: > > >> From: Emanuel Berg <incal@dataswamp.org> > >> Date: Fri, 02 Feb 2024 08:00:22 +0100 > >> > >> Instead of Emacs finding out who is a new user or old, new and > >> old users alike should find what they look for in Emacs. > >> > >> With configuration, maybe one can have a FAQ specifically for > >> that. If one has the 20 most common configuration use cases > >> listed with Elisp one-liners to do it, that would be a good > >> start. And beyond that, people already have experience anyway. > > > > This idea came up several times here, and was met with a general > > agreement, but no one stepped forward to work on those "most common > > configurations". And it is not easy to do, since the configurations > > depend on the needs of the user (whether the user is a programmer and > > in what language(s), what other tasks and jobs does the user want to > > accomplish in Emacs -- email, todo items, etc.) and also some general > > user preferences (mouse vs keyboard etc.). > > > > Patches welcome, of course. > > Would it be useful to have a few 'starter' commented init files / > configurations. > This would be a built-in version of personal init files, but very small, > and commented. I think the idea was to have an interactive feature, whereby a user is asked questions regarding his/her preferences and needs, and the related features are then enabled. A related idea was to come up with mostly-independent groups of settings that are suitable for some general usage pattern. For example, someone who needs to develop Python programs might want certain optional features enabled. Having init files like you suggest once again places the burden on the users to read the comments and decide what to do about them. I think this is not the optimal solution. > > Some Emacs commands I suggest for this are: > > > > C-u M-x apropos > > M-x apropos-documentation > > C-h R elisp RET followed by 'i' (Info-index) and the subject > > Would it make sense to have a specific small section in the Emacs manual > that > Then a link to that manual section could be provided early on > A sort of 'discoverability start point'? We already have it: see the beginning of the "Help" node in the user manual. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-03 12:12 ` Eli Zaretskii @ 2024-02-03 14:07 ` Jeremy Bryant 2024-02-03 15:15 ` Eli Zaretskii 0 siblings, 1 reply; 78+ messages in thread From: Jeremy Bryant @ 2024-02-03 14:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: incal, emacs-devel >> > Patches welcome, of course. >> >> Would it be useful to have a few 'starter' commented init files / >> configurations. >> This would be a built-in version of personal init files, but very small, >> and commented. > > I think the idea was to have an interactive feature, whereby a user is > asked questions regarding his/her preferences and needs, and the > related features are then enabled. > > A related idea was to come up with mostly-independent groups of > settings that are suitable for some general usage pattern. For > example, someone who needs to develop Python programs might want > certain optional features enabled. > > Having init files like you suggest once again places the burden on the > users to read the comments and decide what to do about them. I think > this is not the optimal solution. I understand. How should this be implemented, would this be a new file in the Emacs tree, or part of an existing file. I can volunteer to work on an early prototype. > >> > Some Emacs commands I suggest for this are: >> > >> > C-u M-x apropos >> > M-x apropos-documentation >> > C-h R elisp RET followed by 'i' (Info-index) and the subject >> >> Would it make sense to have a specific small section in the Emacs manual >> that >> Then a link to that manual section could be provided early on >> A sort of 'discoverability start point'? > > We already have it: see the beginning of the "Help" node in the user > manual. Good. As part of a discoverability feature, perhaps we could link to this node in more places, eg in C-h C-h itself ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-03 14:07 ` Jeremy Bryant @ 2024-02-03 15:15 ` Eli Zaretskii 2024-02-04 22:18 ` Jeremy Bryant 0 siblings, 1 reply; 78+ messages in thread From: Eli Zaretskii @ 2024-02-03 15:15 UTC (permalink / raw) To: Jeremy Bryant; +Cc: incal, emacs-devel > From: Jeremy Bryant <jb@jeremybryant.net> > Cc: incal@dataswamp.org, emacs-devel@gnu.org > Date: Sat, 03 Feb 2024 14:07:19 +0000 > > > I think the idea was to have an interactive feature, whereby a user is > > asked questions regarding his/her preferences and needs, and the > > related features are then enabled. > > > > A related idea was to come up with mostly-independent groups of > > settings that are suitable for some general usage pattern. For > > example, someone who needs to develop Python programs might want > > certain optional features enabled. > > > > Having init files like you suggest once again places the burden on the > > users to read the comments and decide what to do about them. I think > > this is not the optimal solution. > > I understand. How should this be implemented, would this be a new file > in the Emacs tree, or part of an existing file. > I can volunteer to work on an early prototype. I think a separate file is the best, thanks. > Good. As part of a discoverability feature, perhaps we could link to > this node in more places, eg in C-h C-h itself We could do that, but there's always the discoverability of "C-h C-h" itself... ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-03 15:15 ` Eli Zaretskii @ 2024-02-04 22:18 ` Jeremy Bryant 2024-02-05 12:41 ` Eli Zaretskii 0 siblings, 1 reply; 78+ messages in thread From: Jeremy Bryant @ 2024-02-04 22:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: incal, emacs-devel Eli, Eli Zaretskii <eliz@gnu.org> writes: >> I understand. How should this be implemented, would this be a new file >> in the Emacs tree, or part of an existing file. >> I can volunteer to work on an early prototype. > > I think a separate file is the best, thanks. OK, noted > >> Good. As part of a discoverability feature, perhaps we could link to >> this node in more places, eg in C-h C-h itself > > We could do that, but there's always the discoverability of "C-h C-h" > itself... From emacs -q, the first line is "Get help" which lands in "C-h C-h" THe info node @Help is indeed very useful, but it takes several hops from emacs -q to even get to it (perhaps via the whole manual) I would suggest it would be helpful to insert a reference to @Help in a much more obvious way, perhaps at the top of C-h C-h - Would this be useful as a patch now? - Should this be reserved as part of a 'discoverability' functionality or setting? ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-04 22:18 ` Jeremy Bryant @ 2024-02-05 12:41 ` Eli Zaretskii 0 siblings, 0 replies; 78+ messages in thread From: Eli Zaretskii @ 2024-02-05 12:41 UTC (permalink / raw) To: Jeremy Bryant; +Cc: incal, emacs-devel > From: Jeremy Bryant <jb@jeremybryant.net> > Cc: incal@dataswamp.org, emacs-devel@gnu.org > Date: Sun, 04 Feb 2024 22:18:48 +0000 > > >From emacs -q, the first line is "Get help" which lands in "C-h C-h" > > THe info node @Help is indeed very useful, but it takes several hops > from emacs -q to even get to it (perhaps via the whole manual) > I would suggest it would be helpful to insert a reference to @Help in a > much more obvious way, perhaps at the top of C-h C-h > > - Would this be useful as a patch now? I don't think so. It might actually confuse because people who type "C-h C-h" usually want quick and concise help. > - Should this be reserved as part of a 'discoverability' functionality or setting? The former, I think (IIUC what you mean by that). ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-02 6:43 ` Eli Zaretskii 2024-02-02 7:00 ` Emanuel Berg @ 2024-02-03 11:30 ` Jeremy Bryant 2024-02-03 11:36 ` Moving which-key ELPA package into core - " Jeremy Bryant 2 siblings, 0 replies; 78+ messages in thread From: Jeremy Bryant @ 2024-02-03 11:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: justin, emacs-devel Eli, >> >> Here is a suggestion - include which-key in core and potentially enable >> >> by for new users. >> > >> > How do we detect "new users"? >> >> Good question, how about a user entry on the splashscreen? > > I don't think I understand, please elaborate. Do you mean we will ask > users to say, up front, that they consider themselves "new users", > each time they start a new Emacs session? Perhaps something like a persistent 'new user or discoverability' flag. This would be toggled by the user, and could be suggested by Emacs based on heuristics such as - Absence of init file (.emacs) - First launch of Emacs, maybe a reminder later > >> > Another idea is to add a feature whereby, after some delay after the >> > user types an incomplete key sequence, the buffer usually popped by >> > C-h or '?' pops up automatically. This would be a smaller change in >> > the UX, which might therefore be more easily acceptable even by >> > not-so-new users. >> >> Interesting, which buffer and part of the code is this? >> (it seems to appear in *Help*) > > Yes, it appears in *Help*, and is produced by describe-prefix-bindings > (via prefix-help-command). Thank you for the suggestion, I will look at this part of the code. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Moving which-key ELPA package into core - Re: discoverability, better defaults and which-key in Emacs 2024-02-02 6:43 ` Eli Zaretskii 2024-02-02 7:00 ` Emanuel Berg 2024-02-03 11:30 ` Jeremy Bryant @ 2024-02-03 11:36 ` Jeremy Bryant 2024-02-03 16:34 ` Stefan Monnier 2 siblings, 1 reply; 78+ messages in thread From: Jeremy Bryant @ 2024-02-03 11:36 UTC (permalink / raw) To: Eli Zaretskii, Stefan Kangas, Stefan Monnier, Philip Kaludercic, Philip Kaludercic Cc: justin, emacs-devel > >> > If we include which-key, but do not enable it by default, would that >> > be good enough? >> >> Yes. >> How can I help with this? >> >> Move the .el files from the ELPA package into lisp/ ? >> Manual entry- ? > > Something like that. Philip and Stefan will be able to describe the > details. > Philip, Stefan, kindly provide some guidance on what work is needed? ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Moving which-key ELPA package into core - Re: discoverability, better defaults and which-key in Emacs 2024-02-03 11:36 ` Moving which-key ELPA package into core - " Jeremy Bryant @ 2024-02-03 16:34 ` Stefan Monnier 2024-02-04 22:12 ` Jeremy Bryant 0 siblings, 1 reply; 78+ messages in thread From: Stefan Monnier @ 2024-02-03 16:34 UTC (permalink / raw) To: Jeremy Bryant Cc: Eli Zaretskii, Stefan Kangas, Philip Kaludercic, Philip Kaludercic, justin, emacs-devel >>> Move the .el files from the ELPA package into lisp/ ? >>> Manual entry- ? >> Something like that. Philip and Stefan will be able to describe the >> details. > Philip, Stefan, kindly provide some guidance on what work is needed? There's no predefined way to do it. The details depend on what you/we care about (e.g. do we want to keep updating the GNU ELPA `which-key` package in the future? If so, do we want to do that by having a separate upstream from which we "pull" both into `elpa.git` and `emacs.git` or do we prefer to generate the GNU ELPA package directly out of the `emacs.git` code? ...). And most of it can be figured out along the way (i.e. fixed after the fact), so I'd say to "just do it" and fix the problems you see as they come up. Stefan ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Moving which-key ELPA package into core - Re: discoverability, better defaults and which-key in Emacs 2024-02-03 16:34 ` Stefan Monnier @ 2024-02-04 22:12 ` Jeremy Bryant 2024-02-04 23:06 ` Stefan Monnier 0 siblings, 1 reply; 78+ messages in thread From: Jeremy Bryant @ 2024-02-04 22:12 UTC (permalink / raw) To: Stefan Monnier Cc: Eli Zaretskii, Stefan Kangas, Philip Kaludercic, Philip Kaludercic, justin, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >>>> Move the .el files from the ELPA package into lisp/ ? >>>> Manual entry- ? >>> Something like that. Philip and Stefan will be able to describe the >>> details. >> Philip, Stefan, kindly provide some guidance on what work is needed? > > There's no predefined way to do it. The details depend on what you/we > care about (e.g. do we want to keep updating the GNU ELPA `which-key` > package in the future? If so, do we want to do that by having > a separate upstream from which we "pull" both into `elpa.git` and > `emacs.git` or do we prefer to generate the GNU ELPA package directly > out of the `emacs.git` code? ...). > > And most of it can be figured out along the way (i.e. fixed after the > fact), so I'd say to "just do it" and fix the problems you see as they > come up. > > > Stefan Thank you, based on this, I have submitted a patch as bug #68929 If, as appears in the original email, the package is no longer maintained upstream, it could be maintained in emacs.git ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Moving which-key ELPA package into core - Re: discoverability, better defaults and which-key in Emacs 2024-02-04 22:12 ` Jeremy Bryant @ 2024-02-04 23:06 ` Stefan Monnier 0 siblings, 0 replies; 78+ messages in thread From: Stefan Monnier @ 2024-02-04 23:06 UTC (permalink / raw) To: Jeremy Bryant Cc: Eli Zaretskii, Stefan Kangas, Philip Kaludercic, Philip Kaludercic, justin, emacs-devel > Thank you, based on this, I have submitted a patch as bug #68929 > > If, as appears in the original email, the package is no longer > maintained upstream, it could be maintained in emacs.git Sounds good to me, Stefan ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-01 7:35 ` Eli Zaretskii 2024-02-01 21:16 ` Jeremy Bryant @ 2024-02-01 21:17 ` orzodk 2024-02-01 22:24 ` Jeremy Bryant 2024-02-02 6:31 ` Eli Zaretskii 2024-02-02 16:00 ` Howard Melman 2 siblings, 2 replies; 78+ messages in thread From: orzodk @ 2024-02-01 21:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Jeremy Bryant, justin, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Jeremy Bryant <jb@jeremybryant.net> >> Date: Wed, 31 Jan 2024 23:23:29 +0000 >> >> A recent theme of discussion has been improving discoverability of Emacs >> features, and in a related way, 'better defaults'. >> >> Here is a suggestion - include which-key in core and potentially enable >> by for new users. > > How do we detect "new users"? As a new user, I ran through help-with-tutorial early on. Maybe adding a note or suggestion somewhere there is good enough. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-01 21:17 ` orzodk @ 2024-02-01 22:24 ` Jeremy Bryant 2024-02-01 23:49 ` orzodk 2024-02-02 6:31 ` Eli Zaretskii 1 sibling, 1 reply; 78+ messages in thread From: Jeremy Bryant @ 2024-02-01 22:24 UTC (permalink / raw) To: orzodk; +Cc: Eli Zaretskii, justin, emacs-devel >> >> How do we detect "new users"? > > As a new user, I ran through help-with-tutorial early on. Maybe adding a > note or suggestion somewhere there is good enough. Do you mean the TUTORIAL accessible through C-h t? ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-01 22:24 ` Jeremy Bryant @ 2024-02-01 23:49 ` orzodk 0 siblings, 0 replies; 78+ messages in thread From: orzodk @ 2024-02-01 23:49 UTC (permalink / raw) To: Jeremy Bryant; +Cc: Eli Zaretskii, justin, emacs-devel Jeremy Bryant <jb@jeremybryant.net> writes: >>> >>> How do we detect "new users"? >> >> As a new user, I ran through help-with-tutorial early on. Maybe adding a >> note or suggestion somewhere there is good enough. > > Do you mean the TUTORIAL accessible through C-h t? Yes. C-h t is bound to the help-with-tutorial function by default. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-01 21:17 ` orzodk 2024-02-01 22:24 ` Jeremy Bryant @ 2024-02-02 6:31 ` Eli Zaretskii 1 sibling, 0 replies; 78+ messages in thread From: Eli Zaretskii @ 2024-02-02 6:31 UTC (permalink / raw) To: orzodk; +Cc: jb, justin, emacs-devel > From: orzodk <orzodk@fastmail.com> > Cc: Jeremy Bryant <jb@jeremybryant.net>, justin@burkett.cc, > emacs-devel@gnu.org > Date: Thu, 01 Feb 2024 14:17:12 -0700 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> Here is a suggestion - include which-key in core and potentially enable > >> by for new users. > > > > How do we detect "new users"? > > As a new user, I ran through help-with-tutorial early on. Maybe adding a > note or suggestion somewhere there is good enough. That's unreliable. Users read the tutorial a small number of times, and a note buried inside it somewhere will go unnoticed or will be forgotten. And what about new users who bypass the tutorial completely? In any case, the suggestion to which I responded was to _enable_ which-keys for such users, not just to tell them the feature exists. If we are going to enable which-keys for some class of users, it is IMO very important to be able to identify them with almost no false positives, because otherwise the enabled feature might annoy users who don't expect these popups. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-01 7:35 ` Eli Zaretskii 2024-02-01 21:16 ` Jeremy Bryant 2024-02-01 21:17 ` orzodk @ 2024-02-02 16:00 ` Howard Melman 2024-02-02 19:24 ` Eli Zaretskii 2 siblings, 1 reply; 78+ messages in thread From: Howard Melman @ 2024-02-02 16:00 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> Here is a suggestion - include which-key in core and potentially enable >> by for new users. > > How do we detect "new users"? I wonder if a mechanism like disabling could be used? According to the elisp manual: "Disabling is used for commands which might be confusing to beginning users, to prevent them from using the commands by accident." Maybe a different property could exist for commands or modes that are enabled by default for beginners and when used could prompt to disable them if the user wants? -- Howard ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-02 16:00 ` Howard Melman @ 2024-02-02 19:24 ` Eli Zaretskii 2024-02-02 19:32 ` tomas 0 siblings, 1 reply; 78+ messages in thread From: Eli Zaretskii @ 2024-02-02 19:24 UTC (permalink / raw) To: Howard Melman; +Cc: emacs-devel > From: Howard Melman <hmelman@gmail.com> > Date: Fri, 02 Feb 2024 11:00:30 -0500 > > > Eli Zaretskii <eliz@gnu.org> writes: > > >> Here is a suggestion - include which-key in core and potentially enable > >> by for new users. > > > > How do we detect "new users"? > > I wonder if a mechanism like disabling could be used? > > According to the elisp manual: > > "Disabling is used for commands which might be confusing to > beginning users, to prevent them from using the commands by > accident." > > Maybe a different property could exist for commands or modes > that are enabled by default for beginners and when used > could prompt to disable them if the user wants? Since we are talking about _enabling_ the feature, the above would mean that veteran users will need to be asked whether to _disable_ it. Wouldn't that be an annoyance? ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-02 19:24 ` Eli Zaretskii @ 2024-02-02 19:32 ` tomas 2024-02-02 20:16 ` Howard Melman 0 siblings, 1 reply; 78+ messages in thread From: tomas @ 2024-02-02 19:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Howard Melman, emacs-devel [-- Attachment #1: Type: text/plain, Size: 495 bytes --] On Fri, Feb 02, 2024 at 09:24:55PM +0200, Eli Zaretskii wrote: [...] > Since we are talking about _enabling_ the feature, the above would > mean that veteran users will need to be asked whether to _disable_ it. > Wouldn't that be an annoyance? For this one it would, yes. An unexpected popup can ruin my day. So I'd really, really like to know that it is actually going to help someone, then I'd be willing to go the extra mile and disable it for me. Cheers & thanks -- t [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-02 19:32 ` tomas @ 2024-02-02 20:16 ` Howard Melman 2024-02-03 7:25 ` Emanuel Berg 2024-02-03 8:49 ` Eli Zaretskii 0 siblings, 2 replies; 78+ messages in thread From: Howard Melman @ 2024-02-02 20:16 UTC (permalink / raw) To: emacs-devel <tomas@tuxteam.de> writes: > On Fri, Feb 02, 2024 at 09:24:55PM +0200, Eli Zaretskii wrote: > >> Since we are talking about _enabling_ the feature, the >> above would mean that veteran users will need to be asked >> whether to _disable_ it. Wouldn't that be an annoyance? > > For this one it would, yes. An unexpected popup can ruin > my day. If, like disabling works, it would write to the init and it would be a one-time annoyance, I don't think it's a big deal. If this debuted with a handful of beginner features configured as such, the NEWS could mention it and tell vererans to put a small block of code in their init to turn off things they don't want. Veterans are more likely to read NEWS than newbies. > So I'd really, really like to know that it is actually > going to help someone, then I'd be willing to go the extra > mile and disable it for me. A lot of newbies find which-key very useful. I'm a long time user and often find it useful. Especially for "newfangled" prefixes like M-g, M-s, C-x x, etc. :) I don't know what other beginner features might qualify, that would have to be evaluated carefully, but for a few, this idea occurred to me as a way to have it enabled for newbies using a small variation of a mechanism that exists for a similar purpose. -- Howard ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-02 20:16 ` Howard Melman @ 2024-02-03 7:25 ` Emanuel Berg 2024-02-03 8:49 ` Eli Zaretskii 1 sibling, 0 replies; 78+ messages in thread From: Emanuel Berg @ 2024-02-03 7:25 UTC (permalink / raw) To: emacs-devel Howard Melman wrote: > A lot of newbies find which-key very useful. I'm a long time > user and often find it useful. Especially for "newfangled" > prefixes like M-g, M-s, C-x x, etc. :) > > I don't know what other beginner features might qualify [...] I don't like the division between beginners and veterans necessarily but here is such a feature, possibly. [ Note the exotic interface BTW with interactive recursion. ] ;;; -*- lexical-binding: t -*- ;; ;; this file: ;; https://dataswamp.org/~incal/emacs-init/show-command.el (defun show-key-command (&optional key cmd) (interactive) (let*((key-ps "hit key(s)!") (ps (if cmd (format "%s %s " cmd key-ps) key-ps) ) (k (or key (read-key-sequence-vector ps))) (new-cmd (key-binding k)) (cmd-or-undef (if new-cmd (format "`%s'" new-cmd) "undefined")) ) (if (and key cmd) (string= new-cmd cmd) (if key (message "%s" cmd-or-undef) (unless (equal k [7]) ; [7] is C-g or `keyboard-quit' (show-key-command nil cmd-or-undef) ))))) ;; (show-key-command) ;; ^ eval me (provide 'show-command) -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-02 20:16 ` Howard Melman 2024-02-03 7:25 ` Emanuel Berg @ 2024-02-03 8:49 ` Eli Zaretskii 2024-02-03 16:58 ` [External] : " Drew Adams 2024-02-04 18:34 ` Howard Melman 1 sibling, 2 replies; 78+ messages in thread From: Eli Zaretskii @ 2024-02-03 8:49 UTC (permalink / raw) To: Howard Melman; +Cc: emacs-devel > From: Howard Melman <hmelman@gmail.com> > Date: Fri, 02 Feb 2024 15:16:29 -0500 > > <tomas@tuxteam.de> writes: > > > On Fri, Feb 02, 2024 at 09:24:55PM +0200, Eli Zaretskii wrote: > > > >> Since we are talking about _enabling_ the feature, the > >> above would mean that veteran users will need to be asked > >> whether to _disable_ it. Wouldn't that be an annoyance? > > > > For this one it would, yes. An unexpected popup can ruin > > my day. > > If, like disabling works, it would write to the init and it > would be a one-time annoyance, I don't think it's a big > deal. I tend to think it's a big deal. But maybe we could look at the result of (get 'narrow-to-region 'disabled) to deduce that if that is nil, we are dealing with a user who is not new, even if the key-bindings popup is not disabled. If which-key is also turned off in "emacs -Q", perhaps that would be good enough? And I still think that automatically popping up the *Help* buffer produced by describe-prefix-bindings is simpler and more coherent with the rest of Emacs than what which-key does. We could still import which-key as an optional feature, of course, even if the automatic popup of describe-prefix-bindings is implemented. ^ permalink raw reply [flat|nested] 78+ messages in thread
* RE: [External] : Re: discoverability, better defaults and which-key in Emacs 2024-02-03 8:49 ` Eli Zaretskii @ 2024-02-03 16:58 ` Drew Adams 2024-02-04 22:25 ` Jeremy Bryant 2024-02-05 3:52 ` Divya Ranjan 2024-02-04 18:34 ` Howard Melman 1 sibling, 2 replies; 78+ messages in thread From: Drew Adams @ 2024-02-03 16:58 UTC (permalink / raw) To: Eli Zaretskii, Howard Melman; +Cc: emacs-devel@gnu.org Not to distract, but FYI library `keysee.el' is an alternative to which-key. Less known, some differences, maybe worth checking out. In particular, it lets you sort key-completion candidates in different ways interactively: - By key name alphabetically, prefix keys first - By key name alphabetically, local keys first - By command name alphabetically - Off (no sorting) You can cycle among them during completion using `C-,` (default of option `sorti-sort-cycle-key'). (You can cycle among key choices with `TAB', per standard option `completion-cycle-threshold'.) Two global minor modes: - `kc-mode': on-demand completion with `S-TAB' (default of option `kc-completion-keys') - `kc-auto-mode': completion after idle delay (also turns on/off `kc-mode', for on-demand) Both provide (1) top-level completion (on-demand: `S-TAB'), which shows you the keys available in the current context, and (2) completion after a prefix key. For top-level completion, choose the keymaps in which to bind `S-TAB' for key completion, using option `kc-keymaps-for-key-completion'. keysee.el uses sortie.el, which provides general interactive sorting of completion candidates (usable for any completion). ___ https://www.emacswiki.org/emacs/KeySee https://www.emacswiki.org/emacs/download/keysee.el ___ https://www.emacswiki.org/emacs/Sortie https://www.emacswiki.org/emacs/download/sortie.el ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [External] : Re: discoverability, better defaults and which-key in Emacs 2024-02-03 16:58 ` [External] : " Drew Adams @ 2024-02-04 22:25 ` Jeremy Bryant 2024-02-04 22:55 ` Emanuel Berg 2024-02-04 23:47 ` Drew Adams 2024-02-05 3:52 ` Divya Ranjan 1 sibling, 2 replies; 78+ messages in thread From: Jeremy Bryant @ 2024-02-04 22:25 UTC (permalink / raw) To: Drew Adams; +Cc: Eli Zaretskii, Howard Melman, emacs-devel Drew Adams <drew.adams@oracle.com> writes: > Not to distract, but FYI library `keysee.el' is > an alternative to which-key. Less known, some > differences, maybe worth checking out. Interesting It seems you are author? Would you suggest this as a candidate for core or ELPA? ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [External] : Re: discoverability, better defaults and which-key in Emacs 2024-02-04 22:25 ` Jeremy Bryant @ 2024-02-04 22:55 ` Emanuel Berg 2024-02-05 3:40 ` Emanuel Berg 2024-02-04 23:47 ` Drew Adams 1 sibling, 1 reply; 78+ messages in thread From: Emanuel Berg @ 2024-02-04 22:55 UTC (permalink / raw) To: emacs-devel Jeremy Bryant wrote: >> Not to distract, but FYI library `keysee.el' is an >> alternative to which-key. Less known, some differences, >> maybe worth checking out. > > Interesting > It seems you are author? > Would you suggest this as a candidate for core or ELPA? Note that if he put his stuff in GNU ELPA, he would still be allowed to mention it on this list and have it on the EmacsWiki. With a reference to the ELPA package, could be beneficial. -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [External] : Re: discoverability, better defaults and which-key in Emacs 2024-02-04 22:55 ` Emanuel Berg @ 2024-02-05 3:40 ` Emanuel Berg 0 siblings, 0 replies; 78+ messages in thread From: Emanuel Berg @ 2024-02-05 3:40 UTC (permalink / raw) To: emacs-devel >>> Not to distract, but FYI library `keysee.el' is an >>> alternative to which-key. Less known, some differences, >>> maybe worth checking out. >> >> Interesting It seems you are author? Would you suggest this >> as a candidate for core or ELPA? > > Note that if he put his stuff in GNU ELPA, he would still be > allowed to mention it on this list and have it on the > EmacsWiki "allowed", encouraged. If y'all just read what I think, not what I type. -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 78+ messages in thread
* RE: [External] : Re: discoverability, better defaults and which-key in Emacs 2024-02-04 22:25 ` Jeremy Bryant 2024-02-04 22:55 ` Emanuel Berg @ 2024-02-04 23:47 ` Drew Adams 2024-02-05 1:46 ` Emanuel Berg 1 sibling, 1 reply; 78+ messages in thread From: Drew Adams @ 2024-02-04 23:47 UTC (permalink / raw) To: Jeremy Bryant; +Cc: Eli Zaretskii, Howard Melman, emacs-devel@gnu.org > > Not to distract, but FYI library `keysee.el' is > > an alternative to which-key. Less known, some > > differences, maybe worth checking out. > > Interesting > It seems you are author? > Would you suggest this as a candidate for core or ELPA? Doesn't matter to me. Just posted the info as an FYI. Keysee does things differently from which-key, but there are many similarities. Probably no reason to provide both as part of Emacs. But perhaps some of the keysee features are of interest. I think maybe which-key has by now implemented some of them (e.g. on-demand, in addition to automatic? top-level, in addition to post-prefix?), but I'm no expert on this. I mentioned on-the-fly sorting. That, plus ability to also match against command names (or combinations of key and command names) are a couple features that I think which-key might lack. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [External] : Re: discoverability, better defaults and which-key in Emacs 2024-02-04 23:47 ` Drew Adams @ 2024-02-05 1:46 ` Emanuel Berg 0 siblings, 0 replies; 78+ messages in thread From: Emanuel Berg @ 2024-02-05 1:46 UTC (permalink / raw) To: emacs-devel Drew Adams wrote: >>> Not to distract, but FYI library `keysee.el' is an >>> alternative to which-key. Less known, some differences, >>> maybe worth checking out. >> >> Interesting >> It seems you are author? >> Would you suggest this as a candidate for core or ELPA? > > Doesn't matter to me It matters to other people if you want them to use your software, they are much more unlikely to read your post here or find it randomly on the EmacsWiki and install it manually, than if it is a repository package ready to be installed using an interface for that purpose that they already know. But for the record I'm probably even worse than you in this respect, I have 196 files of Elisp, 10 980 sloc, and only made a single package for GNU ELPA of all of that. And never added anything to the EmacsWiki :$ Not saying all of that is useful to anyone else or even me, of course, but I think maybe I could and should make two or three more packages for the repos of the stuff I'm most happy with. [Just difficult to figure out what that is, exactly? I don't even know what parts I myself use since I just use it without thinking by now.] And I think it is a good idea for you as well, so other people can benefit from what you have created. -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [External] : Re: discoverability, better defaults and which-key in Emacs 2024-02-03 16:58 ` [External] : " Drew Adams 2024-02-04 22:25 ` Jeremy Bryant @ 2024-02-05 3:52 ` Divya Ranjan 2024-02-05 15:04 ` Drew Adams 1 sibling, 1 reply; 78+ messages in thread From: Divya Ranjan @ 2024-02-05 3:52 UTC (permalink / raw) To: emacs-devel Drew Adams <drew.adams@oracle.com> writes: > Not to distract, but FYI library `keysee.el' is > an alternative to which-key. Less known, some > differences, maybe worth checking out. The dependency on `sortie.el` is actually cumbersome, that said `keysee.el` implements a totally non-intrusive mini-buffer completion for keybinding suggestions. I remember using `which-key` and implementing golden-ratio to my windows, things messed up because `which-key` suggestions are in a proper window, thus potentially intrusive. One can fix this, as a lot of people do but if this is to be integrated into core Emacs one needs to take care of that. Honestly, I believe if we can just add it as a part of the customizable UI then it'd be great. Just like we have `ido-completion`, or the ability to have menu items on the GUI, we can add a keybinding completion system and put it on the manual. People should discover it from Emacs Manual, as they discover other things such as customizing the UI. Making such features immediately visible to the user is a complex problem to solve, which can't be solved right away. But a feature like this _can_ be implemented and should be alongside the discussion on discoverability and what 'defaults' Emacs should be shipped with. Regards, Divya ^ permalink raw reply [flat|nested] 78+ messages in thread
* RE: [External] : Re: discoverability, better defaults and which-key in Emacs 2024-02-05 3:52 ` Divya Ranjan @ 2024-02-05 15:04 ` Drew Adams 0 siblings, 0 replies; 78+ messages in thread From: Drew Adams @ 2024-02-05 15:04 UTC (permalink / raw) To: Divya Ranjan, emacs-devel@gnu.org > > Not to distract, but FYI library `keysee.el' is > > an alternative to which-key. Less known, some > > differences, maybe worth checking out. > > The dependency on `sortie.el` is actually cumbersome, Sortie is completely general - independent of keysee (which depends on it). Sortie can be used to interactively sort candidates for any kind of completion. I think this sorting is important enough for KeySee that it should require Sortie, not make its use optional. Of course, if Emacs already had Sortie or an equivalent then no explicit requiring would be needed by KeySee. ;-) > `keysee.el` implements a totally non-intrusive > mini-buffer completion for keybinding suggestions. > > I remember using `which-key` and implementing > golden-ratio to my windows, things messed up > because `which-key` suggestions are in a > proper window, thus potentially intrusive. > One can fix this, as a lot of people do but if > this is to be integrated into core Emacs one > needs to take care of that. That's indeed another difference. I'm likely less aware of all the differences because I don't use which-key. ;-) (I don't use KeySee either, in fact. I use Icicles. KeySee is actually a reduced-functionality version of Icicles key completion.) The main difference from which-key is no doubt that KeySee completes against key _names_ (and their command names, as I mentioned), and not keystrokes themselves. This means that you type text to complete key names, instead of hitting those keys themselves. [As a shortcut, `M-q <keystroke>' inserts the name of <keystroke>, so you can get almost the same effect as which-key, when you want that. It would be possible/easy to even obviate needing to hit `RET', but I haven't added that option (except in Icicles).] KeySee is thus a bit less just-hit-keys and a bit more of a discover-and-explore feature. In particular, this means you can, any time, fully explore the entire domain of keys available at that time (current context). You can always, for example, _backtrack_, that is, go back up from wherever you are, down inside a sequence of prefix keys. E.g., after getting down into `C-x 4' you can go back up to completing just `C-x'. And then you can go back down again, or down another prefix key's branch (e.g. `C-x 8'), etc. You go up by using the always-available (except at top level) special completion `..', that is, you type `..' to go back up from completing a prefix key. The domain of "keys" available includes the forest of menu-bar menus. So you can use KeySee to explore those as well. And a separate command, `kc-complete-menu-bar' does _only_ that: complete menu-bar menus. > Honestly, I believe if we can just add it > as a part of the customizable UI then it'd > be great. Just like we have `ido-completion`, > or the ability to have menu items on the GUI, > we can add a keybinding completion system > and put it on the manual. People should > discover it from Emacs Manual, as they > discover other things such as customizing > the UI. Making such features immediately > visible to the user is a complex problem to > solve, which can't be solved right away. > But a feature like this _can_ be implemented > and should be alongside the discussion on > discoverability and what 'defaults' Emacs > should be shipped with. The use of KeySee features is, and should be, optional. You turn them on/off using minor modes. As for inclusion of KeySee & Sortie in Emacs, I should say that I don't particularly want to develop/maintain them in/for Emacs. If someone wants to do that, they can do so. They're tiny libraries. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: discoverability, better defaults and which-key in Emacs 2024-02-03 8:49 ` Eli Zaretskii 2024-02-03 16:58 ` [External] : " Drew Adams @ 2024-02-04 18:34 ` Howard Melman 1 sibling, 0 replies; 78+ messages in thread From: Howard Melman @ 2024-02-04 18:34 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > But maybe we could look at the result of > > (get 'narrow-to-region 'disabled) > > to deduce that if that is nil, we are dealing with a user who is not > new, even if the key-bindings popup is not disabled. If which-key is > also turned off in "emacs -Q", perhaps that would be good enough? I don't have a strong opinion but that sounds viable. Linking it to narrow-to-region seem unrelated, though I see the point. > And I still think that automatically popping up the *Help* buffer > produced by describe-prefix-bindings is simpler and more coherent with > the rest of Emacs than what which-key does. We could still import > which-key as an optional feature, of course, even if the automatic > popup of describe-prefix-bindings is implemented. Again, I don't have a strong opinion. Automatically popping up a display of bindings is useful. Bonus points for being able to customize the sorting (e.g., by key or command) globally, per prefix or on-the-fly. which-key also leverages some "Custom String Replacement Options" that make the display more useful. -- Howard ^ permalink raw reply [flat|nested] 78+ messages in thread
end of thread, other threads:[~2024-02-11 20:36 UTC | newest] Thread overview: 78+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-01-31 23:23 discoverability, better defaults and which-key in Emacs Jeremy Bryant 2024-02-01 2:45 ` Po Lu 2024-02-03 13:40 ` Philip Kaludercic 2024-02-04 22:03 ` Dmitry Gutov 2024-02-05 7:11 ` Philip Kaludercic 2024-02-05 15:38 ` Dmitry Gutov 2024-02-05 18:47 ` Philip Kaludercic 2024-02-05 19:17 ` Dmitry Gutov 2024-02-05 19:33 ` Justin Burkett 2024-02-05 23:05 ` Dmitry Gutov 2024-02-06 2:49 ` Justin Burkett 2024-02-06 23:12 ` Dmitry Gutov 2024-02-07 12:35 ` Eli Zaretskii 2024-02-07 18:31 ` Dmitry Gutov 2024-02-07 19:13 ` Eli Zaretskii 2024-02-07 19:51 ` Dmitry Gutov 2024-02-08 1:46 ` Visuwesh 2024-02-08 6:59 ` Eli Zaretskii 2024-02-08 12:18 ` Dmitry Gutov 2024-02-08 13:02 ` Eli Zaretskii 2024-02-08 13:36 ` Dmitry Gutov 2024-02-08 13:52 ` Eli Zaretskii 2024-02-08 14:43 ` Dmitry Gutov 2024-02-08 16:12 ` Dmitry Gutov 2024-02-11 2:17 ` Dmitry Gutov 2024-02-11 2:39 ` Po Lu 2024-02-11 12:30 ` Dmitry Gutov 2024-02-11 6:49 ` Eli Zaretskii 2024-02-11 12:26 ` Dmitry Gutov 2024-02-11 15:00 ` Eli Zaretskii 2024-02-11 20:36 ` Dmitry Gutov 2024-02-08 16:50 ` Eli Zaretskii 2024-02-08 13:41 ` Dmitry Gutov 2024-02-08 13:51 ` Rebinding Fn [Re: discoverability, better defaults and which-key in Emacs] Alan Mackenzie 2024-02-08 13:55 ` Eli Zaretskii 2024-02-08 14:04 ` Alan Mackenzie 2024-02-08 13:25 ` discoverability, better defaults and which-key in Emacs Po Lu 2024-02-08 13:27 ` Dmitry Gutov 2024-02-08 13:36 ` Dmitry Gutov 2024-02-01 7:35 ` Eli Zaretskii 2024-02-01 21:16 ` Jeremy Bryant 2024-02-02 6:43 ` Eli Zaretskii 2024-02-02 7:00 ` Emanuel Berg 2024-02-02 7:43 ` Eli Zaretskii 2024-02-02 15:25 ` [External] : " Drew Adams 2024-02-02 15:53 ` Emanuel Berg 2024-02-02 16:04 ` Emanuel Berg 2024-02-03 11:46 ` Jeremy Bryant 2024-02-03 11:39 ` Jeremy Bryant 2024-02-03 12:12 ` Eli Zaretskii 2024-02-03 14:07 ` Jeremy Bryant 2024-02-03 15:15 ` Eli Zaretskii 2024-02-04 22:18 ` Jeremy Bryant 2024-02-05 12:41 ` Eli Zaretskii 2024-02-03 11:30 ` Jeremy Bryant 2024-02-03 11:36 ` Moving which-key ELPA package into core - " Jeremy Bryant 2024-02-03 16:34 ` Stefan Monnier 2024-02-04 22:12 ` Jeremy Bryant 2024-02-04 23:06 ` Stefan Monnier 2024-02-01 21:17 ` orzodk 2024-02-01 22:24 ` Jeremy Bryant 2024-02-01 23:49 ` orzodk 2024-02-02 6:31 ` Eli Zaretskii 2024-02-02 16:00 ` Howard Melman 2024-02-02 19:24 ` Eli Zaretskii 2024-02-02 19:32 ` tomas 2024-02-02 20:16 ` Howard Melman 2024-02-03 7:25 ` Emanuel Berg 2024-02-03 8:49 ` Eli Zaretskii 2024-02-03 16:58 ` [External] : " Drew Adams 2024-02-04 22:25 ` Jeremy Bryant 2024-02-04 22:55 ` Emanuel Berg 2024-02-05 3:40 ` Emanuel Berg 2024-02-04 23:47 ` Drew Adams 2024-02-05 1:46 ` Emanuel Berg 2024-02-05 3:52 ` Divya Ranjan 2024-02-05 15:04 ` Drew Adams 2024-02-04 18:34 ` Howard Melman
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.