bug#68236: [PATCH] help.el: allow help-quick to use local commands/quick-sections

bug#68236: [PATCH] help.el: allow help-quick to use local commands/quick-sections

[JD Smith]

Someone came up with the great idea of using help.el’s `help-quick' command for a personal “scratch pad” of useful/hard-to-remember bindings, and then to bind `help-quick-sections' locally in various modes.  Unfortunately, `help-quick' first sets the buffer to *Quick Help* and then builds its list of command bindings and descriptions.  This means that only the default value of `help-quick-sections’ will ever be consulted, and no local key bindings can be expressed.  

The fix is simple; build the list of quick help information first in the current buffer (from which C-h C-q is called) and then displaying it in the *Quick Help* buffer.  With this, people can use quick help and its handy binding to prompt with their own personal hard-to-remember key bindings/command info.  What’s cool is that help-quick omits “empty” sections, so you could even add a variety of sections, and they will appear if and only if bindings are actually available in the buffer where quick help is invoked.

+++
diff -u lisp/help.el lisp/help_fix_quick.el
--- lisp/help.el	2024-01-03 21:54:46
+++ lisp/help_fix_quick.el	2024-01-03 21:52:46
@@ -173,78 +173,79 @@
 (defun help-quick ()
   "Display a quick-help buffer."
   (interactive)
-  (with-current-buffer (get-buffer-create "*Quick Help*")
-    (let ((inhibit-read-only t) (padding 2) blocks)
+  (let ((buf (get-buffer-create "*Quick Help*"))
+	(inhibit-read-only t) (padding 2) blocks)
 
-      ;; Go through every section and prepare a text-rectangle to be
-      ;; inserted later.
-      (dolist (section help-quick-sections)
-        (let ((max-key-len 0) (max-cmd-len 0) keys)
-          (dolist (ent (reverse (cdr section)))
-            (catch 'skip
-              (let* ((bind (where-is-internal (car ent) nil t))
-                     (key (if bind
-                              (propertize
-                               (key-description bind)
-                               'face 'help-key-binding)
-                            (throw 'skip nil))))
-                (setq max-cmd-len (max (length (cdr ent)) max-cmd-len)
-                      max-key-len (max (length key) max-key-len))
-                (push (list key (cdr ent) (car ent)) keys))))
-          (when keys
-            (let ((fmt (format "%%-%ds %%-%ds%s" max-key-len max-cmd-len
-                               (make-string padding ?\s)))
-                  (width (+ max-key-len 1 max-cmd-len padding)))
-              (push `(,width
-                      ,(propertize
-                        (concat
-                         (car section)
-                         (make-string (- width (length (car section))) ?\s))
-                        'face 'bold)
-                      ,@(mapcar (lambda (ent)
-                                  (format fmt
-                                          (propertize
-                                           (car ent)
-                                           'quick-help-cmd
-                                           (caddr ent))
-                                          (cadr ent)))
-                                keys))
-                    blocks)))))
+    ;; Go through every section and prepare a text-rectangle to be
+    ;; inserted later.
+    (dolist (section help-quick-sections)
+      (let ((max-key-len 0) (max-cmd-len 0) keys)
+        (dolist (ent (reverse (cdr section)))
+          (catch 'skip
+	    (let* ((bind (where-is-internal (car ent) nil t))
+                   (key (if bind
+			    (propertize
+			     (key-description bind)
+			     'face 'help-key-binding)
+                          (throw 'skip nil))))
+              (setq max-cmd-len (max (length (cdr ent)) max-cmd-len)
+		    max-key-len (max (length key) max-key-len))
+              (push (list key (cdr ent) (car ent)) keys))))
+        (when keys
+          (let ((fmt (format "%%-%ds %%-%ds%s" max-key-len max-cmd-len
+			     (make-string padding ?\s)))
+                (width (+ max-key-len 1 max-cmd-len padding)))
+	    (push `(,width
+		    ,(propertize
+                      (concat
+                       (car section)
+                       (make-string (- width (length (car section))) ?\s))
+                      'face 'bold)
+		    ,@(mapcar (lambda (ent)
+                                (format fmt
+                                        (propertize
+                                         (car ent)
+                                         'quick-help-cmd
+                                         (caddr ent))
+                                        (cadr ent)))
+                              keys))
+                  blocks)))))
 
-      ;; Insert each rectangle in order until they don't fit into the
-      ;; frame any more, in which case the next sections are inserted
-      ;; in a new "line".
+    ;; Insert each rectangle in order until they don't fit into the
+    ;; frame any more, in which case the next sections are inserted
+    ;; in a new "line".
+    (with-current-buffer buf
       (erase-buffer)
       (dolist (block (nreverse blocks))
-        (when (> (+ (car block) (current-column)) (frame-width))
+	(when (> (+ (car block) (current-column)) (frame-width))
           (goto-char (point-max))
           (newline 2))
-        (save-excursion
+	(save-excursion
           (insert-rectangle (cdr block)))
-        (end-of-line))
+	(end-of-line))
       (delete-trailing-whitespace)
 
       (save-excursion
-        (goto-char (point-min))
-        (while-let ((match (text-property-search-forward 'quick-help-cmd)))
+	(goto-char (point-min))
+	(while-let ((match (text-property-search-forward 'quick-help-cmd)))
           (make-text-button (prop-match-beginning match)
                             (prop-match-end match)
                             'mouse-face 'highlight
                             'button t
                             'keymap button-map
                             'action #'describe-symbol
-                            'button-data (prop-match-value match)))))
+                            'button-data (prop-match-value match))))
 
-    (help-mode)
+      (help-mode))
 
     ;; Display the buffer at the bottom of the frame...
-    (with-selected-window (display-buffer-at-bottom (current-buffer) '())
+    (with-selected-window (display-buffer-at-bottom buf '())
       ;; ... mark it as dedicated to prevent focus from being stolen
       (set-window-dedicated-p (selected-window) t)
       ;; ... and shrink it immediately.
-      (fit-window-to-buffer))
-    (message
-     (substitute-command-keys "Toggle the quick help buffer using \\[help-quick-toggle]."))))
+      (fit-window-to-buffer)))
+  (message
+   (substitute-command-keys "Toggle the quick help buffer using \\[help-quick-toggle].")))
 
 (defun help-quick-toggle ()
   "Toggle the quick-help window."

bug#68236: [PATCH] help.el: allow help-quick to use local commands/quick-sections

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Wed, 3 Jan 2024 22:08:56 -0500
> 
> Someone came up with the great idea of using help.el’s `help-quick' command for a personal “scratch pad” of useful/hard-to-remember bindings, and then to bind `help-quick-sections' locally in various modes.  Unfortunately, `help-quick' first sets the buffer to *Quick Help* and then builds its list of command bindings and descriptions.  This means that only the default value of `help-quick-sections’ will ever be consulted, and no local key bindings can be expressed.  
> 
> The fix is simple; build the list of quick help information first in the current buffer (from which C-h C-q is called) and then displaying it in the *Quick Help* buffer.  With this, people can use quick help and its handy binding to prompt with their own personal hard-to-remember key bindings/command info.  What’s cool is that help-quick omits “empty” sections, so you could even add a variety of sections, and they will appear if and only if bindings are actually available in the buffer where quick help is invoked.

Please describe in more detail how would people use this for their
personal "quick help", because I don't think I understand well enough
what you have in mind.

In any case, such a change will need suitable changes for
documentation.

Thanks.

bug#68236: [PATCH] help.el: allow help-quick to use local commands/quick-sections

[JD Smith]

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



> On Jan 4, 2024, at 2:39 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> Please describe in more detail how would people use this for their
> personal "quick help", because I don't think I understand well enough
> what you have in mind.

For example, an org user may

(add-to-list 'help-quick-sections
             '("Org"
	       (org-ctrl-c-star . "Compute table/change heading ")
	       (org-ctrl-c-ret . "Table hline/insert heading")))

so that from org-buffers, C-h C-q adds a new section:

Org                                  
C-c *   Compute table/change heading 
C-c RET Table hline/insert heading   

Most likely users willing to customize `help-quick-sections’ would remove existing sections with commands they know well.  

> In any case, such a change will need suitable changes for
> documentation.

Do you mean documentation for the `help-quick-sections' variable?  How about turning this into a defcustom?  This would allow more advanced users to fully customize what “quick help” they want.

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

bug#68236: [PATCH] help.el: allow help-quick to use local commands/quick-sections

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Thu, 4 Jan 2024 08:45:50 -0500
> Cc: 68236@debbugs.gnu.org
> 
>  On Jan 4, 2024, at 2:39 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>  Please describe in more detail how would people use this for their
>  personal "quick help", because I don't think I understand well enough
>  what you have in mind.
> 
> For example, an org user may
> 
> (add-to-list 'help-quick-sections
>              '("Org"
>       (org-ctrl-c-star . "Compute table/change heading ")
>       (org-ctrl-c-ret . "Table hline/insert heading")))
> 
> so that from org-buffers, C-h C-q adds a new section:
> 
> Org                                  
> C-c *   Compute table/change heading 
> C-c RET Table hline/insert heading   
> 
> Most likely users willing to customize `help-quick-sections’ would remove existing sections with
> commands they know well.  
> 
>  In any case, such a change will need suitable changes for
>  documentation.
> 
> Do you mean documentation for the `help-quick-sections' variable?  How about turning this into a
> defcustom?  This would allow more advanced users to fully customize what “quick help” they want.

If we are going to expose help-quick-sections as a defcustom, then I
don't understand why we need to change the code at all.  Is the idea
that sections will depend on the current buffer?  If so, then we just
need to add an element to the list members which will store the
major-mode for which the member is relevant.

Or what am I missing?

bug#68236: [PATCH] help.el: allow help-quick to use local commands/quick-sections

[JD Smith]

> On Jan 4, 2024, at 8:57 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: JD Smith <jdtsmith@gmail.com>
>> Date: Thu, 4 Jan 2024 08:45:50 -0500
>> Cc: 68236@debbugs.gnu.org
>> 
>> On Jan 4, 2024, at 2:39 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>> Please describe in more detail how would people use this for their
>> personal "quick help", because I don't think I understand well enough
>> what you have in mind.
>> 
>> For example, an org user may
>> 
>> (add-to-list 'help-quick-sections
>>             '("Org"
>>      (org-ctrl-c-star . "Compute table/change heading ")
>>      (org-ctrl-c-ret . "Table hline/insert heading")))
>> 
>> so that from org-buffers, C-h C-q adds a new section:
>> 
>> Org                                  
>> C-c *   Compute table/change heading 
>> C-c RET Table hline/insert heading   
>> 
>> Most likely users willing to customize `help-quick-sections’ would remove existing sections with
>> commands they know well.  
>> 
>> In any case, such a change will need suitable changes for
>> documentation.
>> 
>> Do you mean documentation for the `help-quick-sections' variable?  How about turning this into a
>> defcustom?  This would allow more advanced users to fully customize what “quick help” they want.
> 
> If we are going to expose help-quick-sections as a defcustom, then I
> don't understand why we need to change the code at all.  Is the idea
> that sections will depend on the current buffer?  If so, then we just
> need to add an element to the list members which will store the
> major-mode for which the member is relevant.
> 
> Or what am I missing?

Right now the code does

  (with-current-buffer (get-buffer-create "*Quick Help*")

right away, then checks `where-is-internal' for each listed command in `help-quick-sections'.  So only global bindings (and bindings available in help-mode) are accessible for display.  My patch simply delays switching to *Quick Help* buffer, so that binding information can be gathered from the local buffer from which quick help was summoned.  Note that help-quick omits any bindings that are nil, as well as any empty sections.  So adding sections to the defcustom that do not apply (=have no bindings) in some buffer is not a problem.  

bug#68236: [PATCH] help.el: allow help-quick to use local commands/quick-sections

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Thu, 4 Jan 2024 20:28:27 -0500
> Cc: 68236@debbugs.gnu.org
> 
> > On Jan 4, 2024, at 8:57 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> > If we are going to expose help-quick-sections as a defcustom, then I
> > don't understand why we need to change the code at all.  Is the idea
> > that sections will depend on the current buffer?  If so, then we just
> > need to add an element to the list members which will store the
> > major-mode for which the member is relevant.
> > 
> > Or what am I missing?
> 
> Right now the code does
> 
>   (with-current-buffer (get-buffer-create "*Quick Help*")
> 
> right away, then checks `where-is-internal' for each listed command in `help-quick-sections'.  So only global bindings (and bindings available in help-mode) are accessible for display.  My patch simply delays switching to *Quick Help* buffer, so that binding information can be gathered from the local buffer from which quick help was summoned.  Note that help-quick omits any bindings that are nil, as well as any empty sections.  So adding sections to the defcustom that do not apply (=have no bindings) in some buffer is not a problem.  

Your proposal has the disadvantage that the user must switch to a
buffer under some major mode to see the entries for that mode in the
quick-help window.  It could be an annoyance; e.g., consider a user
who wants to see this while in a *Help* buffer.  And I don't think
being in the buffer under the major mode is the only way of getting
mode-specific bindings; for example, where-is-internal can accept a
KEYMAP argument, which will be used to find key bindings.

Or maybe we should have a separate command for cheat sheets specific
to a major mode.  The window we pop up cannot be too large, so if the
user only wants a quick help for the current mode, she might consider
global bindings an annoying waste of screen estate.  Moreover, the
current quick help shows "popular commands", which are likely to be
already known to some users, whereas when the user works in a major
mode that is new to the user, one is likely to be in the need of the
cheat sheet for that one mode.  (Yes, we do already have "C-h b", but
the output of that could be overwhelming: for example in an Org buffer
I get almost 1400 lines in the *Help* buffer showing the Org-specific
bindings.)

IOW, if we want to consider mode-specific quick help, we should
perhaps discuss more about the goals before we consider code tricks to
implement it.

Stefan, WDYT?

bug#68236: [PATCH] help.el: allow help-quick to use local commands/quick-sections

[JD Smith]

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



> On Jan 5, 2024, at 3:40 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: JD Smith <jdtsmith@gmail.com>
>> Date: Thu, 4 Jan 2024 20:28:27 -0500
>> Cc: 68236@debbugs.gnu.org
>> 
>>> On Jan 4, 2024, at 8:57 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> 
>>> If we are going to expose help-quick-sections as a defcustom, then I
>>> don't understand why we need to change the code at all.  Is the idea
>>> that sections will depend on the current buffer?  If so, then we just
>>> need to add an element to the list members which will store the
>>> major-mode for which the member is relevant.
>>> 
>>> Or what am I missing?
>> 
>> Right now the code does
>> 
>>  (with-current-buffer (get-buffer-create "*Quick Help*")
>> 
>> right away, then checks `where-is-internal' for each listed command in `help-quick-sections'.  So only global bindings (and bindings available in help-mode) are accessible for display.  My patch simply delays switching to *Quick Help* buffer, so that binding information can be gathered from the local buffer from which quick help was summoned.  Note that help-quick omits any bindings that are nil, as well as any empty sections.  So adding sections to the defcustom that do not apply (=have no bindings) in some buffer is not a problem.  
> 
> Your proposal has the disadvantage that the user must switch to a
> buffer under some major mode to see the entries for that mode in the
> quick-help window.  It could be an annoyance; e.g., consider a user
> who wants to see this while in a *Help* buffer.  And I don't think
> being in the buffer under the major mode is the only way of getting
> mode-specific bindings; for example, where-is-internal can accept a
> KEYMAP argument, which will be used to find key bindings.

The current disadvantage is related, but much worse than this: you currently cannot configure quick help to show any bindings other than global and help-mode bindings.  It might be nice to see e.g. org-bindings from anywhere, but to me it’s an advantage to show “quick help for this mode”.

> Or maybe we should have a separate command for cheat sheets specific
> to a major mode.  The window we pop up cannot be too large, so if the
> user only wants a quick help for the current mode, she might consider
> global bindings an annoying waste of screen estate.  

I’d probably disable most of the global bindings, since I already know those.  But some are useful (e.g. I often forget the project bindings).  

> Moreover, the
> current quick help shows "popular commands", which are likely to be
> already known to some users, whereas when the user works in a major
> mode that is new to the user, one is likely to be in the need of the
> cheat sheet for that one mode.  (Yes, we do already have "C-h b", but
> the output of that could be overwhelming: for example in an Org buffer
> I get almost 1400 lines in the *Help* buffer showing the Org-specific
> bindings.)

Agree, this is a real problem for discoverability.  Also command names are not always informative enough to find what you are actually looking for (org is terrible for this).

> IOW, if we want to consider mode-specific quick help, we should
> perhaps discuss more about the goals before we consider code tricks to
> implement it.

I do like this idea.  Perhaps mode authors could add a “starter pack” of this information themselves, if they are suitably admonished to keep this information brief, high level, and with clear few-word command descriptions.  Perhaps adding a ‘help-quick property to the mode command symbol?  

One guiding principle I suggest: users in the end should be able to decide what quick help they need; what’s memorable for some may be frequently forgotten for others. 


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

bug#68236: [PATCH] help.el: allow help-quick to use local commands/quick-sections

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> Right now the code does
>>
>>   (with-current-buffer (get-buffer-create "*Quick Help*")
>>
>> right away, then checks `where-is-internal' for each listed command
>> in `help-quick-sections'.  So only global bindings (and bindings
>> available in help-mode) are accessible for display.  My patch simply
>> delays switching to *Quick Help* buffer, so that binding information
>> can be gathered from the local buffer from which quick help was
>> summoned.  Note that help-quick omits any bindings that are nil, as
>> well as any empty sections.  So adding sections to the defcustom that
>> do not apply (=have no bindings) in some buffer is not a problem.
>
> Your proposal has the disadvantage that the user must switch to a
> buffer under some major mode to see the entries for that mode in the
> quick-help window.  It could be an annoyance; e.g., consider a user
> who wants to see this while in a *Help* buffer.  And I don't think
> being in the buffer under the major mode is the only way of getting
> mode-specific bindings; for example, where-is-internal can accept a
> KEYMAP argument, which will be used to find key bindings.

Yes, this is a problem.  I see the quick help as basically intended for
global Emacs keys, so I think they should display the global ones
always.  Let's not break that.

> Or maybe we should have a separate command for cheat sheets specific
> to a major mode.  The window we pop up cannot be too large, so if the
> user only wants a quick help for the current mode, she might consider
> global bindings an annoying waste of screen estate.  Moreover, the
> current quick help shows "popular commands", which are likely to be
> already known to some users, whereas when the user works in a major
> mode that is new to the user, one is likely to be in the need of the
> cheat sheet for that one mode.  (Yes, we do already have "C-h b", but
> the output of that could be overwhelming: for example in an Org buffer
> I get almost 1400 lines in the *Help* buffer showing the Org-specific
> bindings.)
>
> IOW, if we want to consider mode-specific quick help, we should
> perhaps discuss more about the goals before we consider code tricks to
> implement it.

I think a more specific cheat sheet for major modes would be more
suitable, yes.

Here's an idea that I've had:

Typically, I only want to remember a few commands in each major mode.
It would be useful to be able to mark them for highlighting or somesuch
in the general describe-mode *Help* buffer (preferably using keys, and
not using M-x customize, though they could persist by saving the result
to the custom file).  Then, the next time I display `describe-mode',
they would be highlighted, in this or future sessions.  How about
something like that?

We could also add a separate command to show only those commands somehow
in a similar way to `help-quick-toggle'.

bug#68236: [PATCH] help.el: allow help-quick to use local commands/quick-sections

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 10 Jan 2024 04:51:48 -0800
> Cc: 68236@debbugs.gnu.org, Philip Kaludercic <philipk@posteo.net>
> 
> I think a more specific cheat sheet for major modes would be more
> suitable, yes.
> 
> Here's an idea that I've had:
> 
> Typically, I only want to remember a few commands in each major mode.
> It would be useful to be able to mark them for highlighting or somesuch
> in the general describe-mode *Help* buffer (preferably using keys, and
> not using M-x customize, though they could persist by saving the result
> to the custom file).  Then, the next time I display `describe-mode',
> they would be highlighted, in this or future sessions.  How about
> something like that?
> 
> We could also add a separate command to show only those commands somehow
> in a similar way to `help-quick-toggle'.

Something along these lines, yes.

bug#68236: [PATCH] help.el: allow help-quick to use local commands/quick-sections

[JD Smith]

> On Jan 10, 2024, at 7:51 AM, Stefan Kangas <stefankangas@gmail.com> wrote:
> 
> We could also add a separate command to show only those commands somehow
> in a similar way to `help-quick-toggle'.

One advantage of this approach is you can craft your *own* short command description, if the docstring or command name is not clear to you (things like org-ctrl-return being prime examples).  But what about instead of a separate command to remember, just creating an (optional) section in the existing help-quick popup, for local commands?  where-is-internal would consult the global keymap for the global commands, and the current buffer’s keymap for the locals. 

bug#68236: [PATCH] help.el: allow help-quick to use local commands/quick-sections

[Stefan Kangas]

JD Smith <jdtsmith@gmail.com> writes:

>> On Jan 10, 2024, at 7:51 AM, Stefan Kangas <stefankangas@gmail.com> wrote:
>>
>> We could also add a separate command to show only those commands
>> somehow in a similar way to `help-quick-toggle'.
>
> One advantage of this approach is you can craft your *own* short
> command description, if the docstring or command name is not clear to
> you (things like org-ctrl-return being prime examples).  But what
> about instead of a separate command to remember, just creating an
> (optional) section in the existing help-quick popup, for local
> commands?  where-is-internal would consult the global keymap for the
> global commands, and the current buffer’s keymap for the locals.

That might make sense, yes.  In that case, perhaps we could also add an
option to disable the global keybindings, for advanced users, so that
only the mode specific ones were displayed.

But I would separate this into two changes:
- A "cheatsheet" module
- Support for the cheatsheet module in help-quick-toggle

Because I can then imagine other ways of displaying and using the
cheatsheets (such as the way I proposed).  IOW, I would avoid tightly
coupling the cheatsheet functionality to help-quick-toggle.

bug#68236: [PATCH] help.el: allow help-quick to use local commands/quick-sections

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Wed, 10 Jan 2024 10:46:22 -0500
> Cc: Eli Zaretskii <eliz@gnu.org>, 68236@debbugs.gnu.org,
>  Philip Kaludercic <philipk@posteo.net>
> 
> But what about instead of a separate command to remember, just creating an (optional) section in the existing help-quick popup, for local commands?  where-is-internal would consult the global keymap for the global commands, and the current buffer’s keymap for the locals. 

I think we should be careful not to add too much to what these
commands display, since otherwise we'd reinvent "C-h b" again.

The whole purpose of help-quick is to present a small list of the most
useful commands and their bindings, and do it in a small window.  As
soon as the buffer is long enough to require scrolling, I think we
will have lost.

bug#68236: [PATCH] help.el: allow help-quick to use local commands/quick-sections

[JD Smith]

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

With my original fix of just allowing buffer-local binding to appear in help-quick, I fully intended to disable most of the global bindings (I don’t need a reminder of C-x C-f) and expected it to be therefore  a smaller and easier to parse mode-specific list.  

Since the user has to take the initiative to modify `help-quick-sections’ in my simple approach, I do not see “loss of global bindings” as a concern; that’s a feature, not a bug, from my perspective.


> On Jan 10, 2024, at 10:58 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: JD Smith <jdtsmith@gmail.com>
>> Date: Wed, 10 Jan 2024 10:46:22 -0500
>> Cc: Eli Zaretskii <eliz@gnu.org>, 68236@debbugs.gnu.org,
>> Philip Kaludercic <philipk@posteo.net>
>> 
>> But what about instead of a separate command to remember, just creating an (optional) section in the existing help-quick popup, for local commands?  where-is-internal would consult the global keymap for the global commands, and the current buffer’s keymap for the locals.
> 
> I think we should be careful not to add too much to what these
> commands display, since otherwise we'd reinvent "C-h b" again.
> 
> The whole purpose of help-quick is to present a small list of the most
> useful commands and their bindings, and do it in a small window.  As
> soon as the buffer is long enough to require scrolling, I think we
> will have lost.


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