all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Include which-key.el in the Emacs distribution
@ 2020-09-08 13:54 Stefan Kangas
  2020-09-08 14:01 ` Ergus
                   ` (3 more replies)
  0 siblings, 4 replies; 34+ messages in thread
From: Stefan Kangas @ 2020-09-08 13:54 UTC (permalink / raw)
  To: emacs-devel; +Cc: Justin Burkett

Dear all,

`which-key' is a package that unobtrusively shows you the available
keybindings at the bottom of the screen upon typing a prefix command
(after a configurable delay).  It is an excellent alternative and
complement to the default help.  See the screenshot here:

    https://raw.githubusercontent.com/justbur/emacs-which-key/master/img/which-key-bottom.png

`which-key' is in GNU ELPA, and was upgraded yesterday:

    https://elpa.gnu.org/packages/which-key.html

I propose to include `which-key' in the default Emacs distribution.
I expect that it will be extremely useful for beginning users, but it also
helps advanced users to quickly look up and discover keybindings.  In my
experience, that is true even in modes you already know deeply.

I've proposed this before, and have not seen any objections so far.
So I'd like to ask here again, to see if people have any concerns or
pointers for how to go about it in practice.

Any comments?

Best regards,
Stefan Kangas

PS. I personally think it should be enabled by default, but we would
    probably do better to first include it as an option for people to
    get more experience with it.



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2020-09-08 13:54 Include which-key.el in the Emacs distribution Stefan Kangas
@ 2020-09-08 14:01 ` Ergus
  2020-09-08 14:16   ` Stefan Kangas
  2020-09-08 17:29   ` Yuan Fu
  2020-09-08 16:22 ` Alfred M. Szmidt
                   ` (2 subsequent siblings)
  3 siblings, 2 replies; 34+ messages in thread
From: Ergus @ 2020-09-08 14:01 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: emacs-devel, Justin Burkett

I can't support this more effusively!!

+10 from my side.

What I don't understand is why the version in elpa is very old (and says
obsolete) compared to the one in melpa.


On Tue, Sep 08, 2020 at 01:54:45PM +0000, Stefan Kangas wrote:
>Dear all,
>
>`which-key' is a package that unobtrusively shows you the available
>keybindings at the bottom of the screen upon typing a prefix command
>(after a configurable delay).  It is an excellent alternative and
>complement to the default help.  See the screenshot here:
>
>    https://raw.githubusercontent.com/justbur/emacs-which-key/master/img/which-key-bottom.png
>
>`which-key' is in GNU ELPA, and was upgraded yesterday:
>
>    https://elpa.gnu.org/packages/which-key.html
>
>I propose to include `which-key' in the default Emacs distribution.
>I expect that it will be extremely useful for beginning users, but it also
>helps advanced users to quickly look up and discover keybindings.  In my
>experience, that is true even in modes you already know deeply.
>
>I've proposed this before, and have not seen any objections so far.
>So I'd like to ask here again, to see if people have any concerns or
>pointers for how to go about it in practice.
>
>Any comments?
>
>Best regards,
>Stefan Kangas
>
>PS. I personally think it should be enabled by default, but we would
>    probably do better to first include it as an option for people to
>    get more experience with it.
>



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2020-09-08 14:01 ` Ergus
@ 2020-09-08 14:16   ` Stefan Kangas
  2020-09-08 17:29   ` Yuan Fu
  1 sibling, 0 replies; 34+ messages in thread
From: Stefan Kangas @ 2020-09-08 14:16 UTC (permalink / raw)
  To: Ergus; +Cc: Justin Burkett, emacs-devel

Ergus <spacibba@aol.com> writes:

> What I don't understand is why the version in elpa is very old (and says
> obsolete) compared to the one in melpa.

This is because MELPA-stable uses the git tag (that says version 3.4.0),
while GNU ELPA uses the "Version" header in the .el file (that says
3.3.2).



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2020-09-08 13:54 Include which-key.el in the Emacs distribution Stefan Kangas
  2020-09-08 14:01 ` Ergus
@ 2020-09-08 16:22 ` Alfred M. Szmidt
  2020-09-08 17:24   ` Eli Zaretskii
  2020-09-08 18:25 ` Caio Henrique
  2020-09-08 19:19 ` Stefan Monnier
  3 siblings, 1 reply; 34+ messages in thread
From: Alfred M. Szmidt @ 2020-09-08 16:22 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: justin, emacs-devel

   PS. I personally think it should be enabled by default, but we would
       probably do better to first include it as an option for people to
       get more experience with it.

Could the output be improved though?  The current output is VERY
verbose, and quite bare and unexplanatory.  On my terminal it takes up
9 lines when just hitting C-x.  It also dislikes any type of prefix
command and hides the output from those.  E.g, C-h, M-o etc, where it
eats the message from the original command.

Instead why not if you press C-x in the echo area a short list of
commands could be produced that you can scroll through, similar to
which-key but not as talkative.  It could say,

  C-x 		(f - edit file, o - other window, ...)

The prefix commands C-x 4, C-x r etc could also produces such
messages.  Like Emacs does for M-o.  This list could be curated.

Maybe that would be a nice middle ground, not to talkative, helps the
new user and won't annoy the old farts too much?



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2020-09-08 16:22 ` Alfred M. Szmidt
@ 2020-09-08 17:24   ` Eli Zaretskii
  2020-09-08 17:37     ` Amin Bandali
  0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2020-09-08 17:24 UTC (permalink / raw)
  To: Alfred M. Szmidt; +Cc: stefan, justin, emacs-devel

> From: ams@gnu.org (Alfred M. Szmidt)
> Date: Tue, 08 Sep 2020 12:22:30 -0400
> Cc: justin@burkett.cc, emacs-devel@gnu.org
> 
>    PS. I personally think it should be enabled by default, but we would
>        probably do better to first include it as an option for people to
>        get more experience with it.
> 
> Could the output be improved though?  The current output is VERY
> verbose, and quite bare and unexplanatory.  On my terminal it takes up
> 9 lines when just hitting C-x.  It also dislikes any type of prefix
> command and hides the output from those.  E.g, C-h, M-o etc, where it
> eats the message from the original command.

Btw, did you figure out how to scroll to the next page?  In
particular, after typing "C-h" that shows the first page of Help
commands?



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2020-09-08 14:01 ` Ergus
  2020-09-08 14:16   ` Stefan Kangas
@ 2020-09-08 17:29   ` Yuan Fu
  2020-09-08 17:40     ` Justin Burkett
  1 sibling, 1 reply; 34+ messages in thread
From: Yuan Fu @ 2020-09-08 17:29 UTC (permalink / raw)
  To: Ergus; +Cc: Stefan Kangas, Justin Burkett, emacs-devel



> On Sep 8, 2020, at 10:01 AM, Ergus <spacibba@aol.com> wrote:
> 
> I can't support this more effusively!!
> 
> +10 from my side.


 +1 from me. Which-key could be helpful.

Yuan



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2020-09-08 17:24   ` Eli Zaretskii
@ 2020-09-08 17:37     ` Amin Bandali
  2020-09-08 17:51       ` Alfred M. Szmidt
  2020-09-08 18:00       ` Eli Zaretskii
  0 siblings, 2 replies; 34+ messages in thread
From: Amin Bandali @ 2020-09-08 17:37 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Alfred M. Szmidt, stefan, justin, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]

Eli Zaretskii writes:

>> From: ams@gnu.org (Alfred M. Szmidt)
>> Date: Tue, 08 Sep 2020 12:22:30 -0400
>> Cc: justin@burkett.cc, emacs-devel@gnu.org
>> 
>>    PS. I personally think it should be enabled by default, but we would
>>        probably do better to first include it as an option for people to
>>        get more experience with it.
>> 
>> Could the output be improved though?  The current output is VERY
>> verbose, and quite bare and unexplanatory.  On my terminal it takes up
>> 9 lines when just hitting C-x.  It also dislikes any type of prefix
>> command and hides the output from those.  E.g, C-h, M-o etc, where it
>> eats the message from the original command.
>

The height can be adjusted using `which-key-side-window-max-height' or
`which-key-frame-max-height', depending on which `which-key-popup-type'
you use.

>
> Btw, did you figure out how to scroll to the next page?  In
> particular, after typing "C-h" that shows the first page of Help
> commands?

Pagination is done by hitting C-h C-n and C-h C-p, or C-h n and C-h p
when the which-key popup is active.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2020-09-08 17:29   ` Yuan Fu
@ 2020-09-08 17:40     ` Justin Burkett
  2020-09-08 20:40       ` Stefan Kangas
  0 siblings, 1 reply; 34+ messages in thread
From: Justin Burkett @ 2020-09-08 17:40 UTC (permalink / raw)
  To: Yuan Fu; +Cc: Ergus, Stefan Kangas, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

Hi Everyone,

I'm the author of which-key. For what it's worth, I have no doubt that the
package could be improved. I do have one idea off the top of my head for
how it could be more tightly integrated with emacs.

As far as the amount of output is concerned, it is possible to filter out
keys and customize the output to some degree. You can also limit the size
of the window and control sorting. Of course, emacs does actually have that
many bindings, and that may not be apparent to people unless they are
written out. The original idea was that there would be a significant delay,
so that you wouldn't see the window until you were "stuck".

In any event, I don't have a strong opinion on whether this should happen,
but I have time here and there to help.

Justin

On Tue, Sep 8, 2020 at 1:29 PM Yuan Fu <casouri@gmail.com> wrote:

>
>
> > On Sep 8, 2020, at 10:01 AM, Ergus <spacibba@aol.com> wrote:
> >
> > I can't support this more effusively!!
> >
> > +10 from my side.
>
>
>  +1 from me. Which-key could be helpful.
>
> Yuan
>

[-- Attachment #2: Type: text/html, Size: 1593 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2020-09-08 17:37     ` Amin Bandali
@ 2020-09-08 17:51       ` Alfred M. Szmidt
  2020-09-08 17:54         ` Justin Burkett
  2020-09-08 18:00       ` Eli Zaretskii
  1 sibling, 1 reply; 34+ messages in thread
From: Alfred M. Szmidt @ 2020-09-08 17:51 UTC (permalink / raw)
  To: Amin Bandali; +Cc: eliz, stefan, justin, emacs-devel

   > Btw, did you figure out how to scroll to the next page?  In
   > particular, after typing "C-h" that shows the first page of Help
   > commands?

   Pagination is done by hitting C-h C-n and C-h C-p, or C-h n and C-h p
   when the which-key popup is active.

That was Eli's point -- it doesn't work with C-h -- please try it.

  C-h
  ;; Shows first "C-h (Type ? for further options)-", then after a secondthe
  ;; which-key pop-up occurs.
  C-h
  ;; Now the C-h help help buffer will be shown.
  C-n
  ;; Now you're viewing the NEWS file.

I.e., you cannot paginate through the commands if you are issuing C-h
and have which-key-mode on.
  
  



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2020-09-08 17:51       ` Alfred M. Szmidt
@ 2020-09-08 17:54         ` Justin Burkett
  2020-09-08 18:06           ` Eli Zaretskii
  2020-09-08 18:10           ` Alfred M. Szmidt
  0 siblings, 2 replies; 34+ messages in thread
From: Justin Burkett @ 2020-09-08 17:54 UTC (permalink / raw)
  To: Alfred M. Szmidt; +Cc: Stefan Kangas, Eli Zaretskii, Amin Bandali, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

>
> That was Eli's point -- it doesn't work with C-h -- please try it.
>
>   C-h
>   ;; Shows first "C-h (Type ? for further options)-", then after a
> secondthe
>   ;; which-key pop-up occurs.
>   C-h
>   ;; Now the C-h help help buffer will be shown.
>   C-n
>   ;; Now you're viewing the NEWS file.
>
> I.e., you cannot paginate through the commands if you are issuing C-h
> and have which-key-mode on.


You also can't invoke describe-prefix-bindings from C-h in vanilla emacs.
The reason is the same. which-key is just intercepting the help-char to do
the pagination.

On Tue, Sep 8, 2020 at 1:51 PM Alfred M. Szmidt <ams@gnu.org> wrote:

>    > Btw, did you figure out how to scroll to the next page?  In
>    > particular, after typing "C-h" that shows the first page of Help
>    > commands?
>
>    Pagination is done by hitting C-h C-n and C-h C-p, or C-h n and C-h p
>    when the which-key popup is active.
>
> That was Eli's point -- it doesn't work with C-h -- please try it.
>
>   C-h
>   ;; Shows first "C-h (Type ? for further options)-", then after a
> secondthe
>   ;; which-key pop-up occurs.
>   C-h
>   ;; Now the C-h help help buffer will be shown.
>   C-n
>   ;; Now you're viewing the NEWS file.
>
> I.e., you cannot paginate through the commands if you are issuing C-h
> and have which-key-mode on.
>
>
>

[-- Attachment #2: Type: text/html, Size: 1951 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: Include which-key.el in the Emacs distribution
       [not found] ` <<E1kFgO6-0000cE-Dj@fencepost.gnu.org>
@ 2020-09-08 17:55   ` Drew Adams
       [not found]   ` <<83sgbskwq8.fsf@gnu.org>
  1 sibling, 0 replies; 34+ messages in thread
From: Drew Adams @ 2020-09-08 17:55 UTC (permalink / raw)
  To: Alfred M. Szmidt, Stefan Kangas; +Cc: justin, emacs-devel

>    PS. I personally think it should be enabled by default, but we would
>        probably do better to first include it as an option for people to
>        get more experience with it.
> 
> Could the output be improved though?  The current output is VERY
> verbose, and quite bare and unexplanatory.  On my terminal it takes up
> 9 lines when just hitting C-x.  It also dislikes any type of prefix
> command and hides the output from those.  E.g, C-h, M-o etc, where it
> eats the message from the original command.
> 
> Instead why not if you press C-x in the echo area a short list of
> commands could be produced that you can scroll through, similar to
> which-key but not as talkative.  It could say,
> 
>   C-x 		(f - edit file, o - other window, ...)
> 
> The prefix commands C-x 4, C-x r etc could also produces such
> messages.  Like Emacs does for M-o.  This list could be curated.
> 
> Maybe that would be a nice middle ground, not to talkative, helps the
> new user and won't annoy the old farts too much?

See also `keysee.el':

No problem with prefix keys/commands (C-h, M-o, etc.).
No problem showing available keys at top level.
No problem navigating back up the key hierarchy - up,
 down, all around.
No problem with menu-bar menus (up, down, all around).
You can match keys, commands, or both.
You can sort matches on the fly:
 * By key name alphabetically, prefix keys first
 * By key name alphabetically, local keys first
 * By command name alphabetically

It does, however, show all matches in *Completions*,
(as opposed to just a few matches in the echo area).

If you have a way of limiting the window height of
*Completions* then that would help reduce the visual
overload you complain about.

But maybe what you really want for that is something
that decides which are the most important keys to
show.  Sorting *Completions* according to such
"importance" (and showing it in a short window)
would help with that.  One easy way to automatically
define such "importance" could be to sort keys by
their recent frequency.

https://www.emacswiki.org/emacs/KeySee

https://www.emacswiki.org/emacs/download/keysee.el
___


(FWIW: If you use Icicles then you have what
keysee.el offers plus much more, including control
over *Completions* display, sort orders etc.

https://www.emacswiki.org/emacs/Icicles_-_Key_Completion)



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2020-09-08 17:37     ` Amin Bandali
  2020-09-08 17:51       ` Alfred M. Szmidt
@ 2020-09-08 18:00       ` Eli Zaretskii
  2020-09-08 19:12         ` Amin Bandali
  1 sibling, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2020-09-08 18:00 UTC (permalink / raw)
  To: Amin Bandali; +Cc: ams, stefan, justin, emacs-devel

> From: Amin Bandali <bandali@gnu.org>
> Cc: ams@gnu.org (Alfred M. Szmidt),  stefan@marxist.se,  justin@burkett.cc,
>   emacs-devel@gnu.org
> Date: Tue, 08 Sep 2020 13:37:27 -0400
> 
> > Btw, did you figure out how to scroll to the next page?  In
> > particular, after typing "C-h" that shows the first page of Help
> > commands?
> 
> Pagination is done by hitting C-h C-n and C-h C-p, or C-h n and C-h p
> when the which-key popup is active.

Did you actually try that after typing C-h?

And even after other prefix keys, like C-x, these paging commands are
highly unintuitive, certainly for an Emacs user, and are not easily
discoverable (are they documented in the README or in some other
place?).

This package "needs work", IMHO.



^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: Include which-key.el in the Emacs distribution
       [not found]   ` <<83sgbskwq8.fsf@gnu.org>
@ 2020-09-08 18:05     ` Drew Adams
  0 siblings, 0 replies; 34+ messages in thread
From: Drew Adams @ 2020-09-08 18:05 UTC (permalink / raw)
  To: Eli Zaretskii, Alfred M. Szmidt; +Cc: stefan, justin, emacs-devel

> to scroll to the next page?  In particular, after typing
> "C-h" that shows the first page of Help commands?

FWIW, this is not a problem for keysee.el.  Scrolling
*Completions* is as usual (TAB), including after C-h.



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2020-09-08 17:54         ` Justin Burkett
@ 2020-09-08 18:06           ` Eli Zaretskii
  2020-09-08 18:11             ` Justin Burkett
  2020-09-08 18:10           ` Alfred M. Szmidt
  1 sibling, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2020-09-08 18:06 UTC (permalink / raw)
  To: Justin Burkett; +Cc: stefan, ams, bandali, emacs-devel

> From: Justin Burkett <justin@burkett.cc>
> Date: Tue, 8 Sep 2020 13:54:08 -0400
> Cc: Amin Bandali <bandali@gnu.org>, Eli Zaretskii <eliz@gnu.org>, Stefan Kangas <stefan@marxist.se>, 
> 	emacs-devel <emacs-devel@gnu.org>
> 
>  I.e., you cannot paginate through the commands if you are issuing C-h
>  and have which-key-mode on.
> 
> You also can't invoke describe-prefix-bindings from C-h in vanilla
> emacs.

I don't see the relevance, sorry.  When I type "C-h" with
which-key-mode on, I see a paging hint at the bottom line, and that
hint simply doesn't work (and nothing else I tried does).  By
contrast, the vanilla "C-h" doesn't say anything about
describe-prefix-bindings, so the problem will rarely if ever happen.

IMO, this UI needs to be improved, certainly if we want to turn this
mode on by default.  For starters, how about using the usual Emacs
scrolling keys for showing the next/previous page?



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2020-09-08 17:54         ` Justin Burkett
  2020-09-08 18:06           ` Eli Zaretskii
@ 2020-09-08 18:10           ` Alfred M. Szmidt
  1 sibling, 0 replies; 34+ messages in thread
From: Alfred M. Szmidt @ 2020-09-08 18:10 UTC (permalink / raw)
  To: Justin Burkett; +Cc: stefan, eliz, bandali, emacs-devel

    That was Eli's point -- it doesn't work with C-h -- please try it.

      C-h
      ;; Shows first "C-h (Type ? for further options)-", then after a secondthe
      ;; which-key pop-up occurs.
      C-h
      ;; Now the C-h help help buffer will be shown.
      C-n
      ;; Now you're viewing the NEWS file.

    I.e., you cannot paginate through the commands if you are issuing C-h
    and have which-key-mode on.

   You also can't invoke describe-prefix-bindings from C-h in vanilla
   emacs. The reason is the same. which-key is just intercepting the
   help-char to do the pagination.

As a user the background reasons for why something is not possible are
not interesting.  which-key tells me to use C-h to visit the next
page; that does not work if you've just hit C-h once already -- it
invokes help-for-help (C-h C-h), which is not what the user is being
told to expect.



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2020-09-08 18:06           ` Eli Zaretskii
@ 2020-09-08 18:11             ` Justin Burkett
  2020-09-08 20:40               ` Stefan Kangas
  0 siblings, 1 reply; 34+ messages in thread
From: Justin Burkett @ 2020-09-08 18:11 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Stefan Kangas, Alfred M. Szmidt, Amin Bandali, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1987 bytes --]

> I don't see the relevance, sorry.  When I type "C-h" with
> which-key-mode on, I see a paging hint at the bottom line, and that
> hint simply doesn't work (and nothing else I tried does).  By
> contrast, the vanilla "C-h" doesn't say anything about
> describe-prefix-bindings, so the problem will rarely if ever happen.
>

Ah, if it's just about the hint, then yes, that should be hidden in that
case.

IMO, this UI needs to be improved, certainly if we want to turn this
> mode on by default.  For starters, how about using the usual Emacs
> scrolling keys for showing the next/previous page?
>

I wasn't advocating for it to be on by default, but yes, the UI could
probably be improved. It's a difficult problem (at least for me), because I
wanted which-key to be passive and not interfere with how emacs processes
key sequences. That's why I used the help-char escape mechanism to do the
paging. As far as the default keys, that's an easy change of course.

On Tue, Sep 8, 2020 at 2:06 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Justin Burkett <justin@burkett.cc>
> > Date: Tue, 8 Sep 2020 13:54:08 -0400
> > Cc: Amin Bandali <bandali@gnu.org>, Eli Zaretskii <eliz@gnu.org>,
> Stefan Kangas <stefan@marxist.se>,
> >       emacs-devel <emacs-devel@gnu.org>
> >
> >  I.e., you cannot paginate through the commands if you are issuing C-h
> >  and have which-key-mode on.
> >
> > You also can't invoke describe-prefix-bindings from C-h in vanilla
> > emacs.
>
> I don't see the relevance, sorry.  When I type "C-h" with
> which-key-mode on, I see a paging hint at the bottom line, and that
> hint simply doesn't work (and nothing else I tried does).  By
> contrast, the vanilla "C-h" doesn't say anything about
> describe-prefix-bindings, so the problem will rarely if ever happen.
>
> IMO, this UI needs to be improved, certainly if we want to turn this
> mode on by default.  For starters, how about using the usual Emacs
> scrolling keys for showing the next/previous page?
>

[-- Attachment #2: Type: text/html, Size: 3104 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2020-09-08 13:54 Include which-key.el in the Emacs distribution Stefan Kangas
  2020-09-08 14:01 ` Ergus
  2020-09-08 16:22 ` Alfred M. Szmidt
@ 2020-09-08 18:25 ` Caio Henrique
  2020-09-08 19:19 ` Stefan Monnier
  3 siblings, 0 replies; 34+ messages in thread
From: Caio Henrique @ 2020-09-08 18:25 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Justin Burkett, emacs-devel

Personally I find it a bit intrusive, so I use it very rarely (maybe once
every one or two months) and I manually load it in those rare occasions
when I want to use it. 
If it were enabled by default, I wouldn't mind having to add a line in
my config to disable it.

Caio Henrique



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2020-09-08 18:00       ` Eli Zaretskii
@ 2020-09-08 19:12         ` Amin Bandali
  0 siblings, 0 replies; 34+ messages in thread
From: Amin Bandali @ 2020-09-08 19:12 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: ams, stefan, justin, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1356 bytes --]

Eli Zaretskii writes:

>> From: Amin Bandali <bandali@gnu.org>
>> Cc: ams@gnu.org (Alfred M. Szmidt),  stefan@marxist.se,  justin@burkett.cc,
>>   emacs-devel@gnu.org
>> Date: Tue, 08 Sep 2020 13:37:27 -0400
>> 
>> > Btw, did you figure out how to scroll to the next page?  In
>> > particular, after typing "C-h" that shows the first page of Help
>> > commands?
>> 
>> Pagination is done by hitting C-h C-n and C-h C-p, or C-h n and C-h p
>> when the which-key popup is active.
>
> Did you actually try that after typing C-h?
>

Oh, my bad; I think I misread/misunderstood your question.  I had indeed
not tried with C-h, but with other prefixes like C-x and C-c.  With
those prefixes, C-h C-n et al. work fine, but it seems that for C-h it
does not.  Sorry for the misunderstanding.

>
> And even after other prefix keys, like C-x, these paging commands are
> highly unintuitive, certainly for an Emacs user, and are not easily
> discoverable (are they documented in the README or in some other
> place?).
>
> This package "needs work", IMHO.
>

I agree, the user interface could be better.  I'm just generally happy
to see which-key discussed on emacs-devel for inclusion in GNU Emacs
itself and possibly being enabled out of the box (perhaps as part of one
of the new layers/modules/themes idea of Stefan and others).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2020-09-08 13:54 Include which-key.el in the Emacs distribution Stefan Kangas
                   ` (2 preceding siblings ...)
  2020-09-08 18:25 ` Caio Henrique
@ 2020-09-08 19:19 ` Stefan Monnier
  2020-09-08 20:14   ` Ergus
  3 siblings, 1 reply; 34+ messages in thread
From: Stefan Monnier @ 2020-09-08 19:19 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Justin Burkett, emacs-devel

> I propose to include `which-key' in the default Emacs distribution.

I think it would be most useful to enable it by default.
But for that it needs to be polished enough that it's still bearable for
those users who don't like it (e.g. the guy with his 1MB .emacs file
that has to use a `emacs -Q` when testing something, or when using
Emacs on someone else's computer/account).


        Stefan




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2020-09-08 19:19 ` Stefan Monnier
@ 2020-09-08 20:14   ` Ergus
  2020-09-08 20:40     ` Stefan Kangas
  0 siblings, 1 reply; 34+ messages in thread
From: Ergus @ 2020-09-08 20:14 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Stefan Kangas, Justin Burkett, emacs-devel

Now I am the one becoming conservative here.

I really love which-key but enabling it by default for everyone could be
a bit premature. Maybe adding a very easy to find option in the toolbar
could be a better first step?

So the ones (like me) who love it can improve it until it becomes ready
to be default without the complains if the other who doesn't.



On Tue, Sep 08, 2020 at 03:19:45PM -0400, Stefan Monnier wrote:
>> I propose to include `which-key' in the default Emacs distribution.
>
>I think it would be most useful to enable it by default.
>But for that it needs to be polished enough that it's still bearable for
>those users who don't like it (e.g. the guy with his 1MB .emacs file
>that has to use a `emacs -Q` when testing something, or when using
>Emacs on someone else's computer/account).
>
>
>        Stefan
>
>



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2020-09-08 18:11             ` Justin Burkett
@ 2020-09-08 20:40               ` Stefan Kangas
  0 siblings, 0 replies; 34+ messages in thread
From: Stefan Kangas @ 2020-09-08 20:40 UTC (permalink / raw)
  To: Justin Burkett, Eli Zaretskii; +Cc: Alfred M. Szmidt, Amin Bandali, emacs-devel

Justin Burkett <justin@burkett.cc> writes:

>> When I type "C-h" with which-key-mode on, I see a paging hint at the
>> bottom line, and that hint simply doesn't work (and nothing else I
>> tried does).
>
> Ah, if it's just about the hint, then yes, that should be hidden in that
> case.

Thanks, I see that you already did that:

https://github.com/justbur/emacs-which-key/commit/a70fc16adcf604f2cb8061d77813354da018c541

> I wasn't advocating for it to be on by default, but yes, the UI could
> probably be improved. It's a difficult problem (at least for me), because I
> wanted which-key to be passive and not interfere with how emacs processes
> key sequences. That's why I used the help-char escape mechanism to do the
> paging. As far as the default keys, that's an easy change of course.

Does it make sense to support all three of n/p, C-n/C-p and C-v/M-v?
While updating the minibuffer help text to promote the more standard key
bindings C-v/M-v?



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2020-09-08 20:14   ` Ergus
@ 2020-09-08 20:40     ` Stefan Kangas
  2022-02-11 21:31       ` Corwin Brust
  0 siblings, 1 reply; 34+ messages in thread
From: Stefan Kangas @ 2020-09-08 20:40 UTC (permalink / raw)
  To: Ergus, Stefan Monnier; +Cc: Justin Burkett, emacs-devel

Ergus <spacibba@aol.com> writes:

> I really love which-key but enabling it by default for everyone could be
> a bit premature. Maybe adding a very easy to find option in the toolbar
> could be a better first step?
>
> So the ones (like me) who love it can improve it until it becomes ready
> to be default without the complains if the other who doesn't.

Yes, we should definitely make any necessary improvements before
considering to make it the default.  I believe that's what Stefan M was
also arguing, so I see no disagreement on that point.



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2020-09-08 17:40     ` Justin Burkett
@ 2020-09-08 20:40       ` Stefan Kangas
  0 siblings, 0 replies; 34+ messages in thread
From: Stefan Kangas @ 2020-09-08 20:40 UTC (permalink / raw)
  To: Justin Burkett, Yuan Fu; +Cc: Ergus, emacs-devel

Justin Burkett <justin@burkett.cc> writes:

> In any event, I don't have a strong opinion on whether this should happen,
> but I have time here and there to help.

Thank you, that is encouraging news.  Your help will be much
appreciated.

The suggestion to make this the default seems to have gotten some
attention, but was perhaps a bit premature.  In any case, I do think
adding this package to the Emacs distribution would already be very
useful in itself.

BTW, I would propose to update the Version header to match (or be higher
than) the latest git tag 3.4.0.  Then we could update ELPA with that new
release.

I take it that the copyright assignments from contributors are all in
order?

Best regards,
Stefan Kangas



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2020-09-08 20:40     ` Stefan Kangas
@ 2022-02-11 21:31       ` Corwin Brust
  2022-02-13 17:30         ` Philip Kaludercic
  2022-02-13 17:59         ` Stephen Leake
  0 siblings, 2 replies; 34+ messages in thread
From: Corwin Brust @ 2022-02-11 21:31 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Ergus, Emacs developers, Stefan Monnier, Justin Burkett

On Tue, Sep 8, 2020 at 3:41 PM Stefan Kangas <stefan@marxist.se> wrote:
>
> Ergus <spacibba@aol.com> writes:
>
> > I really love which-key but enabling it by default for everyone could be
> > a bit premature. Maybe adding a very easy to find option in the toolbar
> > could be a better first step?
> >
> > So the ones (like me) who love it can improve it until it becomes ready
> > to be default without the complains if the other who doesn't.
>
> Yes, we should definitely make any necessary improvements before
> considering to make it the default.  I believe that's what Stefan M was
> also arguing, so I see no disagreement on that point.
>

Hi all.  Having `which-key' available in core remains popular, at least on IRC.

Now that it is available from GNU Elpa I wonder what is left to do and
if there appears hope of including it with Emacs 29.

Does anyone "here" have thoughts on how this may be coming along/what
else is needed?



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2022-02-11 21:31       ` Corwin Brust
@ 2022-02-13 17:30         ` Philip Kaludercic
  2022-02-14  9:04           ` Pankaj Jangid
                             ` (2 more replies)
  2022-02-13 17:59         ` Stephen Leake
  1 sibling, 3 replies; 34+ messages in thread
From: Philip Kaludercic @ 2022-02-13 17:30 UTC (permalink / raw)
  To: Corwin Brust; +Cc: Emacs developers

Corwin Brust <corwin@bru.st> writes:

> On Tue, Sep 8, 2020 at 3:41 PM Stefan Kangas <stefan@marxist.se> wrote:
>>
>> Ergus <spacibba@aol.com> writes:
>>
>> > I really love which-key but enabling it by default for everyone could be
>> > a bit premature. Maybe adding a very easy to find option in the toolbar
>> > could be a better first step?
>> >
>> > So the ones (like me) who love it can improve it until it becomes ready
>> > to be default without the complains if the other who doesn't.
>>
>> Yes, we should definitely make any necessary improvements before
>> considering to make it the default.  I believe that's what Stefan M was
>> also arguing, so I see no disagreement on that point.
>>
>
> Hi all.  Having `which-key' available in core remains popular, at least on IRC.
>
> Now that it is available from GNU Elpa I wonder what is left to do and
> if there appears hope of including it with Emacs 29.

My first question is why it should be added to the core, given that it
can be installed with a single command OOTB?  My impression from using
(and seeing other people use) which-key would have me say that the UX it
provides goes contrary to the "style" that core functionality uses
traditionally (what other cases are there where not doing something
modifies the window configuration, the closes commonly used
functionality would be eldoc that displays information in the
minibuffer).

What I would be more interested in is to add optional support for C-h to
continue a command prefix, so that if I want to know what keys a keymap
provides, I can request it immediately without waiting for the idle
timer to trigger a often too small popup window, without loosing the
partial input.

-- 
	Philip Kaludercic



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2022-02-11 21:31       ` Corwin Brust
  2022-02-13 17:30         ` Philip Kaludercic
@ 2022-02-13 17:59         ` Stephen Leake
  2022-02-13 18:17           ` Corwin Brust
  1 sibling, 1 reply; 34+ messages in thread
From: Stephen Leake @ 2022-02-13 17:59 UTC (permalink / raw)
  To: Corwin Brust
  Cc: Justin Burkett, Ergus, Stefan Kangas, Stefan Monnier,
	Emacs developers

Corwin Brust <corwin@bru.st> writes:

> On Tue, Sep 8, 2020 at 3:41 PM Stefan Kangas <stefan@marxist.se> wrote:
>>
>> Ergus <spacibba@aol.com> writes:
>>
>> > I really love which-key but enabling it by default for everyone could be
>> > a bit premature. Maybe adding a very easy to find option in the toolbar
>> > could be a better first step?
>> >
>> > So the ones (like me) who love it can improve it until it becomes ready
>> > to be default without the complains if the other who doesn't.
>>
>> Yes, we should definitely make any necessary improvements before
>> considering to make it the default.  I believe that's what Stefan M was
>> also arguing, so I see no disagreement on that point.
>>
>
> Hi all.  Having `which-key' available in core remains popular, at least on IRC.
>
> Now that it is available from GNU Elpa I wonder what is left to do and
> if there appears hope of including it with Emacs 29.
>
> Does anyone "here" have thoughts on how this may be coming along/what
> else is needed?

I started on a branch to implement bundling elpa packages in the emacs
release; see feature/bundle-elpa, file admin/notes/elpa, and this email
thread on emacs-devel:
https://lists.gnu.org/archive/html/emacs-devel/2021-01/msg01017.html

I gave up when no one responded to my requests for comments.

There is also a branch feature/core-elpa-by-copy.

-- 
-- Stephe



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2022-02-13 17:59         ` Stephen Leake
@ 2022-02-13 18:17           ` Corwin Brust
  2022-02-13 23:25             ` Stephen Leake
  0 siblings, 1 reply; 34+ messages in thread
From: Corwin Brust @ 2022-02-13 18:17 UTC (permalink / raw)
  To: Stephen Leake
  Cc: Justin Burkett, Ergus, Stefan Kangas, Stefan Monnier,
	Emacs developers

On Sun, Feb 13, 2022 at 11:59 AM Stephen Leake
<stephen_leake@stephe-leake.org> wrote:
>
> Corwin Brust <corwin@bru.st> writes:
>
> > On Tue, Sep 8, 2020 at 3:41 PM Stefan Kangas <stefan@marxist.se> wrote:
> >>
> >> Ergus <spacibba@aol.com> writes:
> >>
> >> > I really love which-key but enabling it by default for everyone could be
> >> > a bit premature. Maybe adding a very easy to find option in the toolbar
> >> > could be a better first step?
> >> >
> >> > So the ones (like me) who love it can improve it until it becomes ready
> >> > to be default without the complains if the other who doesn't.
> >>
> >> Yes, we should definitely make any necessary improvements before
> >> considering to make it the default.  I believe that's what Stefan M was
> >> also arguing, so I see no disagreement on that point.
> >>
> >
> > Hi all.  Having `which-key' available in core remains popular, at least on IRC.
> >
> > Now that it is available from GNU Elpa I wonder what is left to do and
> > if there appears hope of including it with Emacs 29.
> >
> > Does anyone "here" have thoughts on how this may be coming along/what
> > else is needed?
>
> I started on a branch to implement bundling elpa packages in the emacs
> release; see feature/bundle-elpa, file admin/notes/elpa, and this email
> thread on emacs-devel:
> https://lists.gnu.org/archive/html/emacs-devel/2021-01/msg01017.html

Does solving this block the possibility to include which-key, in your view?

I know, at least, ERC is maintained via GNU ELPA but bundled in each
Emacs release.  Would it make sense to look into how that's being
done, perhaps as an interim step?

>
> I gave up when no one responded to my requests for comments.
>
> There is also a branch feature/core-elpa-by-copy.

I'll take a look at these branches and read the thread you mentioned.
I'm not very familiar with the "plumbing" for the ELPAs but perhaps I
can gean so understand from what you've done already.

Thanks for the reply.
>
> --
> -- Stephe



-- 
Corwin
612-217-1742
612-695-4276 (signal)
corwin@bru.st



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2022-02-13 18:17           ` Corwin Brust
@ 2022-02-13 23:25             ` Stephen Leake
  2022-02-14  2:47               ` Stefan Monnier
  0 siblings, 1 reply; 34+ messages in thread
From: Stephen Leake @ 2022-02-13 23:25 UTC (permalink / raw)
  To: Corwin Brust
  Cc: Justin Burkett, Ergus, Stefan Kangas, Stefan Monnier,
	Emacs developers

Corwin Brust <corwin@bru.st> writes:

> On Sun, Feb 13, 2022 at 11:59 AM Stephen Leake
> <stephen_leake@stephe-leake.org> wrote:
>>
>> Corwin Brust <corwin@bru.st> writes:
>>
>> > Hi all.  Having `which-key' available in core remains popular, at least on IRC.
>> >
>> > Now that it is available from GNU Elpa I wonder what is left to do and
>> > if there appears hope of including it with Emacs 29.
>> >
>> > Does anyone "here" have thoughts on how this may be coming along/what
>> > else is needed?
>>
>> I started on a branch to implement bundling elpa packages in the emacs
>> release; see feature/bundle-elpa, file admin/notes/elpa, and this email
>> thread on emacs-devel:
>> https://lists.gnu.org/archive/html/emacs-devel/2021-01/msg01017.html
>
> Does solving this block the possibility to include which-key, in your
> view?

The goal is to have a mechanism to easily include any ELPA package with
the Emacs release. The above is one approach to that.

> I know, at least, ERC is maintained via GNU ELPA but bundled in each
> Emacs release.  Would it make sense to look into how that's being
> done, perhaps as an interim step?

That's easy; there is a lisp/erc directory in the master emacs git
repository. Apparently someone syncs the code between there and ELPA.
There are several other packages that use that approach; which-key could
as well.

There are also "core" ELPA packages; the code resides in the emacs
master repository, but the ELPA server also packages it. I think the
only examples of those are single-file, but it should work for
multi-file as well.

-- 
-- Stephe



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2022-02-13 23:25             ` Stephen Leake
@ 2022-02-14  2:47               ` Stefan Monnier
  2022-02-14  3:09                 ` Justin Burkett
  0 siblings, 1 reply; 34+ messages in thread
From: Stefan Monnier @ 2022-02-14  2:47 UTC (permalink / raw)
  To: Stephen Leake
  Cc: Corwin Brust, Stefan Kangas, Ergus, Emacs developers,
	Justin Burkett

> That's easy; there is a lisp/erc directory in the master emacs git
> repository. Apparently someone syncs the code between there and ELPA.

Not really: the GNU ELPA packages are generated from code kept in the
`elpa.git` repository, but it can also use the code in Emacs itself
(i.e. in the `master` branch of the `emacs.git` repository), which is
what happens for ERC, Python, and a few more, whose "upstream" is
Emacs's own repository.

> There are also "core" ELPA packages; the code resides in the emacs
> master repository, but the ELPA server also packages it. I think the
> only examples of those are single-file, but it should work for
> multi-file as well.

It's not limited to single-file packages.
The ERC package is one of those.


        Stefan




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2022-02-14  2:47               ` Stefan Monnier
@ 2022-02-14  3:09                 ` Justin Burkett
  2022-02-14  3:46                   ` Corwin Brust
  0 siblings, 1 reply; 34+ messages in thread
From: Justin Burkett @ 2022-02-14  3:09 UTC (permalink / raw)
  To: Stefan Monnier
  Cc: Stefan Kangas, Ergus, Corwin Brust, Stephen Leake,
	Emacs developers

[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]

I don't have anything to say about the process of moving it into the core,
but it's fine with me if you all decide to do that. I don't have much time
these days to contribute, however.

Justin

On Sun, Feb 13, 2022 at 9:47 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > That's easy; there is a lisp/erc directory in the master emacs git
> > repository. Apparently someone syncs the code between there and ELPA.
>
> Not really: the GNU ELPA packages are generated from code kept in the
> `elpa.git` repository, but it can also use the code in Emacs itself
> (i.e. in the `master` branch of the `emacs.git` repository), which is
> what happens for ERC, Python, and a few more, whose "upstream" is
> Emacs's own repository.
>
> > There are also "core" ELPA packages; the code resides in the emacs
> > master repository, but the ELPA server also packages it. I think the
> > only examples of those are single-file, but it should work for
> > multi-file as well.
>
> It's not limited to single-file packages.
> The ERC package is one of those.
>
>
>         Stefan
>
>

[-- Attachment #2: Type: text/html, Size: 1516 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2022-02-14  3:09                 ` Justin Burkett
@ 2022-02-14  3:46                   ` Corwin Brust
  0 siblings, 0 replies; 34+ messages in thread
From: Corwin Brust @ 2022-02-14  3:46 UTC (permalink / raw)
  To: Justin Burkett
  Cc: Stefan Kangas, Ergus, Stephen Leake, Stefan Monnier,
	Emacs developers

I'd be happy to help if a "warm body" to "do stuff" is what's needed.

On Sun, Feb 13, 2022 at 9:09 PM Justin Burkett <justin@burkett.cc> wrote:
>
> I don't have anything to say about the process of moving it into the core, but it's fine with me if you all decide to do that. I don't have much time these days to contribute, however.
>
> Justin
>
> On Sun, Feb 13, 2022 at 9:47 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>
>> > That's easy; there is a lisp/erc directory in the master emacs git
>> > repository. Apparently someone syncs the code between there and ELPA.
>>
>> Not really: the GNU ELPA packages are generated from code kept in the
>> `elpa.git` repository, but it can also use the code in Emacs itself
>> (i.e. in the `master` branch of the `emacs.git` repository), which is
>> what happens for ERC, Python, and a few more, whose "upstream" is
>> Emacs's own repository.
>>
>> > There are also "core" ELPA packages; the code resides in the emacs
>> > master repository, but the ELPA server also packages it. I think the
>> > only examples of those are single-file, but it should work for
>> > multi-file as well.
>>
>> It's not limited to single-file packages.
>> The ERC package is one of those.
>>
>>
>>         Stefan
>>



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2022-02-13 17:30         ` Philip Kaludercic
@ 2022-02-14  9:04           ` Pankaj Jangid
  2022-02-14 16:23           ` [External] : " Drew Adams
  2022-02-14 22:09           ` Tim Cross
  2 siblings, 0 replies; 34+ messages in thread
From: Pankaj Jangid @ 2022-02-14  9:04 UTC (permalink / raw)
  To: emacs-devel

Philip Kaludercic <philipk@posteo.net> writes:

> What I would be more interested in is to add optional support for C-h to
> continue a command prefix, so that if I want to know what keys a keymap
> provides, I can request it immediately without waiting for the idle
> timer to trigger a often too small popup window, without loosing the
> partial input.

I’ve enabled default settings of which-key. And that is good enough, at
least for me, so that it pops up on those rare occasions when my muscle
memory is not able to recall something.

But "Manual Activation" feature is available in "which-key". Following
section of README file explains it briefly:

#+begin_src emacs-lisp
;; 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)

;; This will prevent which-key from showing automatically, and allow
;; you to use C-h in the middle of a key sequence to show the which-key
;; buffer and keep it open for the remainder of the key sequence.
#+end_src





^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: [External] : Re: Include which-key.el in the Emacs distribution
  2022-02-13 17:30         ` Philip Kaludercic
  2022-02-14  9:04           ` Pankaj Jangid
@ 2022-02-14 16:23           ` Drew Adams
  2022-02-14 22:09           ` Tim Cross
  2 siblings, 0 replies; 34+ messages in thread
From: Drew Adams @ 2022-02-14 16:23 UTC (permalink / raw)
  To: Philip Kaludercic, Corwin Brust; +Cc: Emacs developers

> What I would be more interested in is to add optional
> support for C-h to continue a command prefix, so that
> if I want to know what keys a keymap provides, I can
> request it immediately without waiting for the idle
> timer to trigger a often too small popup window,
> without loosing the partial input.

I know that you know that `C-h' after a prefix
key shows you the possible continuations.  I
think your request is to not "lose" what you've
typed so far.

Library `keysee.el' can help with this.  It can
either show you possible continuations after a
delay, automatically, or show you them only on
demand, when you hit key `S-TAB' (by default).

You can also use `S-TAB' at top level, to see
all possible keys available in the current
context.

You can also complete menu-bar menus.

Completion candidates are pairs: key name,
followed by a (configurable) separator,
followed by the associated command name.

Completion is normal, so you can use keys to
edit minibuffer content.  This is a difference
from `which-key', where the keys you type just
continue the prefix key directly.  With Key See,
keys you type act normally in the minibuffer.

This means you can match against the key name
or the command name, or against both.

If you do want to have a key you type continue
the key sequence instead of editing minibuffer
content, precede it with `M-q'.  That inserts
its name, for completion.

You can also sort the completion candidates in
these ways (by default - you can add sorts):

 * By key name alphabetically, prefix keys first
 * By key name alphabetically, local keys first
 * By command name alphabetically

Sorting applies to both display and cycling (per
option `completion-cycle-threshold ').  You can
change the current sort order on the fly anytime,
using `C-,' (by default).  A prefix arg (e.g.
`C-u C-,') reverses the current sort order.

The completion styles used are those defined by
option `kc-completion-styles', so they can be
different from what you prefer for general use
(option `completion-styles').

Key See essentially extracts some of what
Icicles key completion provides, as a separate
library.  `keysee.el' requires `sortie.el',
which is what provides for completion sorting. 

If you complete to another prefix key (e.g.
you complete `C-x' to `C-x 4'), the candidates
are changed to those of that key (e.g. `C-x 4').

Whenever you are not at top level (candidates
are those of a prefix key), `..' is available
as a special candidate.  It takes you up a
level, essentially undoing the use of a prefix
key.

This means you can use Key See to navigate up
and down the complete current key hierarchy -
all possible keys (including menu-bar menus).

The on-demand completion behavior is provided
by minor mode `kc-mode'.  The automatic,
timer-based completion is provided by minor
mode `kc-auto-mode'.  It includes on-demand
behavior, so you can still use `S-TAB' at top
level.  To complete only menu-bar menus, you
can use command `kc-complete-menu-bar'.
___

Key See description:

https://www.emacswiki.org/emacs/KeySee

Key See code:

https://www.emacswiki.org/emacs/download/keysee.el

Sortie description:

https://www.emacswiki.org/emacs/Sortie

Sortie code:

https://www.emacswiki.org/emacs/download/sortie.el




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Include which-key.el in the Emacs distribution
  2022-02-13 17:30         ` Philip Kaludercic
  2022-02-14  9:04           ` Pankaj Jangid
  2022-02-14 16:23           ` [External] : " Drew Adams
@ 2022-02-14 22:09           ` Tim Cross
  2 siblings, 0 replies; 34+ messages in thread
From: Tim Cross @ 2022-02-14 22:09 UTC (permalink / raw)
  To: emacs-devel

Philip Kaludercic <philipk@posteo.net> writes:

> Corwin Brust <corwin@bru.st> writes:
>
>> On Tue, Sep 8, 2020 at 3:41 PM Stefan Kangas <stefan@marxist.se> wrote:
>>>
>>> Ergus <spacibba@aol.com> writes:
>>>
>>> > I really love which-key but enabling it by default for everyone could be
>>> > a bit premature. Maybe adding a very easy to find option in the toolbar
>>> > could be a better first step?
>>> >
>>> > So the ones (like me) who love it can improve it until it becomes ready
>>> > to be default without the complains if the other who doesn't.
>>>
>>> Yes, we should definitely make any necessary improvements before
>>> considering to make it the default.  I believe that's what Stefan M was
>>> also arguing, so I see no disagreement on that point.
>>>
>>
>> Hi all.  Having `which-key' available in core remains popular, at least on IRC.
>>
>> Now that it is available from GNU Elpa I wonder what is left to do and
>> if there appears hope of including it with Emacs 29.
>
> My first question is why it should be added to the core, given that it
> can be installed with a single command OOTB?  My impression from using
> (and seeing other people use) which-key would have me say that the UX it
> provides goes contrary to the "style" that core functionality uses
> traditionally (what other cases are there where not doing something
> modifies the window configuration, the closes commonly used
> functionality would be eldoc that displays information in the
> minibuffer).
>
> What I would be more interested in is to add optional support for C-h to
> continue a command prefix, so that if I want to know what keys a keymap
> provides, I can request it immediately without waiting for the idle
> timer to trigger a often too small popup window, without loosing the
> partial input.

Sounds like you would find Embark better than which-key.

While Embark takes more effort to configure, it gives you very similar
functionality as which-key, but provides a lot more and can provide
powerful integration/enhancements for completion frameworks like vertico
or selectrum. 



^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2022-02-14 22:09 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-09-08 13:54 Include which-key.el in the Emacs distribution Stefan Kangas
2020-09-08 14:01 ` Ergus
2020-09-08 14:16   ` Stefan Kangas
2020-09-08 17:29   ` Yuan Fu
2020-09-08 17:40     ` Justin Burkett
2020-09-08 20:40       ` Stefan Kangas
2020-09-08 16:22 ` Alfred M. Szmidt
2020-09-08 17:24   ` Eli Zaretskii
2020-09-08 17:37     ` Amin Bandali
2020-09-08 17:51       ` Alfred M. Szmidt
2020-09-08 17:54         ` Justin Burkett
2020-09-08 18:06           ` Eli Zaretskii
2020-09-08 18:11             ` Justin Burkett
2020-09-08 20:40               ` Stefan Kangas
2020-09-08 18:10           ` Alfred M. Szmidt
2020-09-08 18:00       ` Eli Zaretskii
2020-09-08 19:12         ` Amin Bandali
2020-09-08 18:25 ` Caio Henrique
2020-09-08 19:19 ` Stefan Monnier
2020-09-08 20:14   ` Ergus
2020-09-08 20:40     ` Stefan Kangas
2022-02-11 21:31       ` Corwin Brust
2022-02-13 17:30         ` Philip Kaludercic
2022-02-14  9:04           ` Pankaj Jangid
2022-02-14 16:23           ` [External] : " Drew Adams
2022-02-14 22:09           ` Tim Cross
2022-02-13 17:59         ` Stephen Leake
2022-02-13 18:17           ` Corwin Brust
2022-02-13 23:25             ` Stephen Leake
2022-02-14  2:47               ` Stefan Monnier
2022-02-14  3:09                 ` Justin Burkett
2022-02-14  3:46                   ` Corwin Brust
     [not found] <<CADwFkmmvVRqnQGA_d8bMA66SXbpjis+j-1UiceY7Lk7eY6iugA@mail.gmail.com>
     [not found] ` <<E1kFgO6-0000cE-Dj@fencepost.gnu.org>
2020-09-08 17:55   ` Drew Adams
     [not found]   ` <<83sgbskwq8.fsf@gnu.org>
2020-09-08 18:05     ` Drew Adams

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.