RE: [External] : Re: [DISCUSSION] "quick-help" popup for org-columns (column view)

RE: [External] : Re: [DISCUSSION] "quick-help" popup for org-columns (column view)

[Sławomir Grochowski]

I have been using the https://github.com/justbur/emacs-which-key for a long time.
However, today I took a closer look at this package to see if it has
two features that I've found in 'quick-help' which I really like.

Those two features are:

1. option for popup to be persistent, sticky
It's a lifesaver for every new user to see permanently
available keybindings, as well as for every user who starts
use an unknown package.
'which-key' already has this feature implemented,
variable `which-key-persistent-popup'.

2. option to divide keybindings into groups
For example, with 'which-key' when I press 'C-h',
popup with 50 keybindings will appear on the screen.  
I'm completely overwhelmed by the amount of information.
Making any decision is very tiring and difficult.
Grouping will make it much easier to read and make a decision.
I don't see this functionality in 'which-key' but I found a topic on
Reddit https://www.reddit.com/r/emacs/comments/kxd9z4/grouped_bindings_in_whichkey
with repo link
https://github.com/loafofpiecrust/dotfiles/blob/main/emacs/.config/doom/custom/pretty-which-key.el
where this feature has been implemented.

Based on this information, I think it's worth waiting until 'which-key' is integrated.
And then implement the 'divide keybindings into groups' feature.

I'm not familiar with https://www.emacswiki.org/emacs/download/keysee.el
But I could try to answer some questions about 'which-key'.

Drew Adams <drew.adams@oracle.com> writes:

> 1. Doesn't which-key also provide the
> possibility (e.g., on-demand instead of
> by timer) to show all currently available
> bindings at top level, i.e., not on a
> prefix key)?  I thought it had added that
> feature at some point.
>
> If it doesn't, then that's another big
> difference ("critical", you say) from
> KeySee.

Yes, it's available with command `which-key-show-top-level'.

> 2. As for getting the completions in a
> buffer that you can access "persistently"
> (and, e.g., to search or edit):
>
> There should be a separate, more general
> feature for that: be able to "save" the
> current contents of `*Completions* (or
> another buffer displaying completions) to
> another buffer, regardless of what that
> completions buffer is showing.
>
> IOW, this shouldn't be only about _key_
> completions and descriptions as help.
>
> Icicles provides such a feature (as does
> Embark, IIUC).  Emacs should have it.  Hit
> a key, enter a destination buffer name (or
> just hit RET for a default name).

Yes, you can copy or even edit 'which-key' 'popup'.

> 3. Icicles can also show you complete help
> for key completions shown in *Completions*,
> in *Help*.  And likewise for any other
> kind of completions for which there's a
> help description.
>
> Showing help for completions is another
> general feature that Emacs should have.

I don't know if 'which-key' has this option.

-- 
Sławomir Grochowski

[DISCUSSION] "quick-help" popup for org-columns (column view)

[Sławomir Grochowski]

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

Dear All,

Inspired by "Re: Adding a "quick-help" menu"
https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg01138.html

I've created a "quick-help" for functionality in org-mode - column view
(https://orgmode.org/worg/org-tutorials/org-column-view-tutorial.html)

This is a popup with keybindings available in the 'column view'.
In attachment: screenshot and animated gif to see this in motion.

Function 'help-quick' could be easily modified to take some parameters.
This would allow to create a "help-quick" popups for other packages.
I think it's pretty helpful in column view. 

Please let me know what you think.


[-- Attachment #2: colview-quick-help.png --]
[-- Type: image/png, Size: 104768 bytes --]

[-- Attachment #3: 2024-02-08 16-37-17-colview-quick-help.gif --]
[-- Type: image/gif, Size: 266424 bytes --]

[-- Attachment #4: Type: text/plain, Size: 28 bytes --]


--
Sławomir Grochowski

Re: [DISCUSSION] "quick-help" popup for org-columns (column view)

[Adam Porter]

Since transient.el is part of Emacs now, these kinds of menus should 
probably be implemented with it.

Re: [DISCUSSION] "quick-help" popup for org-columns (column view)

[Stefan Kangas]

Adam Porter <adam@alphapapa.net> writes:

> Since transient.el is part of Emacs now, these kinds of menus should
> probably be implemented with it.

IIUC, this is not a menu, but a reminder of key bindings that are usable
in that context.  Other keybindings here are self-inserting keys, which
are equally useful, and they wouldn't be available in a transient.

Re: [DISCUSSION] "quick-help" popup for org-columns (column view)

[Ihor Radchenko]

Stefan Kangas <stefankangas@gmail.com> writes:

> Adam Porter <adam@alphapapa.net> writes:
>
>> Since transient.el is part of Emacs now, these kinds of menus should
>> probably be implemented with it.
>
> IIUC, this is not a menu, but a reminder of key bindings that are usable
> in that context.  Other keybindings here are self-inserting keys, which
> are equally useful, and they wouldn't be available in a transient.

I am wondering how quick-help, transient, and which-key (AFAIU, it is to
be included into the core soon-ish) play together.

transient provides a specific way to define the displayed layout, among
other things. At the same time, quick-help provides an alternative
(undocumented) way to define the layout. And which-key uses pre-defined
layout.

I am wondering if transient style to define how various options in the
menu/help buffer/which-key buffer can be unified.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [DISCUSSION] "quick-help" popup for org-columns (column view)

[Philip Kaludercic]

Ihor Radchenko <yantar92@posteo.net> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Adam Porter <adam@alphapapa.net> writes:
>>
>>> Since transient.el is part of Emacs now, these kinds of menus should
>>> probably be implemented with it.
>>
>> IIUC, this is not a menu, but a reminder of key bindings that are usable
>> in that context.  Other keybindings here are self-inserting keys, which
>> are equally useful, and they wouldn't be available in a transient.

The point of quick-help is to provide a persistent buffer with useful
bindings, comparable to what Nano does OOTB.

> I am wondering how quick-help, transient, and which-key (AFAIU, it is to
> be included into the core soon-ish) play together.
>
> transient provides a specific way to define the displayed layout, among
> other things. At the same time, quick-help provides an alternative
> (undocumented) way to define the layout. And which-key uses pre-defined
> layout.

One critical difference between which-key and transient compared to
quick-help, is that the latter has nothing to do with prefix maps, but
(by default) just presents global bindings, and is as such closer to a
curated version of `describe-bindings' (sort of like how `shortdocs' is
a curated version of `apropos-functions').

> I am wondering if transient style to define how various options in the
> menu/help buffer/which-key buffer can be unified.

-- 
Philip Kaludercic

RE: [External] : Re: [DISCUSSION] "quick-help" popup for org-columns (column view)

[Drew Adams]

> The point of quick-help is to provide a persistent buffer
> with useful bindings, comparable to what Nano does OOTB.

> One critical difference between which-key and transient
> compared to quick-help, is that the latter has nothing
> to do with prefix maps, but (by default) just presents
> global bindings, and is as such closer to a curated
> version of `describe-bindings' (sort of like how
> `shortdocs' is a curated version of `apropos-functions').

1. Doesn't which-key also provide the
possibility (e.g., on-demand instead of
by timer) to show all currently available
bindings at top level, i.e., not on a
prefix key)?  I thought it had added that
feature at some point.

If it doesn't, then that's another big
difference ("critical", you say) from
KeySee.
___

2. As for getting the completions in a
buffer that you can access "persistently"
(and, e.g., to search or edit):

There should be a separate, more general
feature for that: be able to "save" the
current contents of `*Completions* (or
another buffer displaying completions) to
another buffer, regardless of what that
completions buffer is showing.

IOW, this shouldn't be only about _key_
completions and descriptions as help.

Icicles provides such a feature (as does
Embark, IIUC).  Emacs should have it.  Hit
a key, enter a destination buffer name (or
just hit RET for a default name).
___

3. Icicles can also show you complete help
for key completions shown in *Completions*,
in *Help*.  And likewise for any other
kind of completions for which there's a
help description.

Showing help for completions is another
general feature that Emacs should have.
___

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