unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: JD Smith <jdtsmith@gmail.com>, Stefan Kangas <stefankangas@gmail.com>
Cc: 68236@debbugs.gnu.org
Subject: bug#68236: [PATCH] help.el: allow help-quick to use local commands/quick-sections
Date: Fri, 05 Jan 2024 10:40:02 +0200	[thread overview]
Message-ID: <835y08w4v1.fsf@gnu.org> (raw)
In-Reply-To: <4CB34A88-87DE-4347-A886-4BF8D4998E67@gmail.com> (message from JD Smith on Thu, 4 Jan 2024 20:28:27 -0500)

> 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?





  reply	other threads:[~2024-01-05  8:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-04  3:08 bug#68236: [PATCH] help.el: allow help-quick to use local commands/quick-sections JD Smith
2024-01-04  7:39 ` Eli Zaretskii
2024-01-04 13:45   ` JD Smith
2024-01-04 13:57     ` Eli Zaretskii
2024-01-05  1:28       ` JD Smith
2024-01-05  8:40         ` Eli Zaretskii [this message]
2024-01-05 17:00           ` JD Smith
2024-01-10 12:51           ` Stefan Kangas
2024-01-10 13:53             ` Eli Zaretskii
2024-01-10 15:46             ` JD Smith
2024-01-10 15:50               ` Stefan Kangas
2024-01-10 15:58               ` Eli Zaretskii
2024-01-10 22:49                 ` JD Smith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=835y08w4v1.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=68236@debbugs.gnu.org \
    --cc=jdtsmith@gmail.com \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).