Re: Adding a "quick-help" menu

[Philip Kaludercic]

Gregor Zattler <telegraph@gmx.net> writes:

> Hi Philip, emacs developers,
> * Philip Kaludercic <philipk@posteo.net> [2022-09-16; 17:22 GMT]:
>> Yes, but just like there is a difference between auto-completion and
>> tab-completion, there is a difference to be considered here.
>
> for me the main difference to all other help facilities is,
> that there is zero cognitive burden: It only pops up when I
> hit a prefix key and then don't know what to do.

What kind of prefix keys are we talking about?  Could you give me a
recent example for where which-key was useful to you (or anyone else)?

> It specifically shows help to this prefix key, I do not have
> to move the mouse, I do not have to look for a symbol to
> click or a menu entry which might be related.

But none of this is necessary when you press C-h.  The only disadvantage
is that you would have to repeat the prefix, but I think that could be
changed.

> I do not have to know how to bury or kill it, it does not
> litter my buffer list with jet another buried buffer, it
> does not permanently change my window configuration.

Do you meant the *Help* buffer?

> I think these are great features especially for newbies.
>
>> Again, I don't think there is anything in Emacs by default that relies
>> on non-input the way which-key does.  One reason I dislike this is
>> because I've seen how some people use `which-key-mode' in person, just
>> waiting for the menu to (fragile) pop up, to skim through the columns to
>> find what they are looking for.  By comparison, I think that C-h and
>> isearch/occur/etc. is more idiomatic.
>
> But much more involved to use and they leave traces as
> which-key does not.

I personally think this is an advantage (though I wouldn't put it the
way you did).  To me `which-key' -- the way it is configured by default
-- seems fragile and unreliable.  A help buffer is just-another-buffer
and doesn't appear to be an exception to the rest of how Emacs works.

>> That being said, my proposal is much more modest, and has more to do
>> with Nano's default help bar at the bottom of the screen.
>
> My praise of which-key is in no way directed against your
> proposal of a screen full of essential functions.

Don't worry, I didn't take it that way, I just wanted to return to the
initial topic of the thread.