From: Drew Adams <drew.adams@oracle.com>
To: ndame <emacsuser@freemail.hu>, 36767@debbugs.gnu.org
Subject: bug#36767: 26.1; request: add more quick keys to the *Help* buffer
Date: Mon, 22 Jul 2019 13:49:58 -0700 (PDT) [thread overview]
Message-ID: <54e1a2f5-62df-4bc9-a1bb-7e6c099f9c83@default> (raw)
In-Reply-To: <AxtnEw.onqlxb7Mkpry.ig9TynsmAb80jvlU3CY7@freemail.hu>
This is really two different feature requests, IMO.
Here is a reply to this one (your second one):
> Also, the user may want to read more about the
> symbol if it is a built in one, so add a quick
> way to visit the Info page of the symbol which
> Help is shown. The currently unbound key 'i' is
> suitable for this purpose.
This is the same text I replied to your similar
post in help-gnu-emacs@gnu.org.
----
What you request was discussed very recently on
emacs-devel@gnu.org.
I wrote this there:
Since 2011 library `help-fns+.el' has had that feature.
And it's user configurable - not just on/off, by
option `help-cross-reference-manuals':
1. Choose the list of manuals to search. Default:
Emacs and Elisp manuals.
2. Choose whether to (a) search systematically,
when `*Help*' is created, and add a `manuals'
link only if search finds hits, or (b) always
create a link, and search only when the link
is followed. Default: (b).
https://lists.gnu.org/archive/html/emacs-devel/2019-07/msg00242.html
This feature is implemented by searching the
manuals listed in a user option. By default,
the manuals are Emacs and Elisp. But you can
choose any Info manuals you like.
Now if Emacs itself implemented such a feature
then there might presumably be no need to search
for the right manual location(s) to visit either
(a) when you display the *Help* that contains the
link or (b) when you click the link.
Emacs itself could perhaps have an internal table
that gets populated at build time - at least for
manuals such as Emacs and Elisp.
And if more manuals were chosen by a user (by such
an option) then those additional manuals could be
handled similarly to what `help-fns+.el' does now:
user choice whether to search (a) when *Help* gets
displayed (slow, and useless if there's no match)
or (b) only when you click the link for Info.
Note that the `help-fns+.el' implementation adds
a single link in *Help*. When followed, if there
are hits in both Emacs and Elisp then it goes to
an Info buffer that has a links to each of those
manuals. (If only one manual covers it then the
link takes you directly to that location.)
https://www.emacswiki.org/emacs/download/help-fns%2b.el
----
As for the keys you suggest for your two requested
features: `s' is already bound to `Info-search',
and `i' is already bound to `Info-index'. Those
keys are longstanding and should not be changed.
next prev parent reply other threads:[~2019-07-22 20:49 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-22 19:53 bug#36767: 26.1; request: add more quick keys to the *Help* buffer ndame
2019-07-22 20:49 ` Drew Adams [this message]
2019-07-28 0:10 ` Basil L. Contovounesios
2021-06-15 18:52 ` Lars Ingebrigtsen
2021-06-17 20:34 ` Juri Linkov
2021-06-18 6:02 ` Eli Zaretskii
2021-06-18 7:20 ` Robert Pluim
2021-06-18 10:58 ` Eli Zaretskii
2021-06-18 14:21 ` bug#36767: [External] : " Drew Adams
2021-06-18 14:32 ` Stephen Berman
2021-06-18 14:45 ` Eli Zaretskii
2021-06-18 16:02 ` Stephen Berman
2021-06-18 18:25 ` Eli Zaretskii
2021-06-19 9:08 ` martin rudalics
2021-06-19 9:27 ` Eli Zaretskii
2021-06-20 9:21 ` martin rudalics
2021-06-18 16:21 ` bug#36767: [External] : " Drew Adams
2021-06-18 14:12 ` Drew Adams
2021-06-18 19:14 ` Juri Linkov
2021-06-18 19:21 ` Eli Zaretskii
2021-06-19 23:15 ` Juri Linkov
[not found] ` <AM9PR09MB49779C8B93EFFB329EB8E5A596A29@AM9PR09MB4977.eurprd09.prod.outlook.com>
[not found] ` <83y27nvnb4.fsf@gnu.org>
[not found] ` <AM9PR09MB497767EDF180DE0C3EE15F4396A39@AM9PR09MB4977.eurprd09.prod.outlook.com>
[not found] ` <83ilyrvgda.fsf@gnu.org>
[not found] ` <AM9PR09MB497720FA603D3B7FC4D4739196A39@AM9PR09MB4977.eurprd09.prod.outlook.com>
2021-09-23 20:54 ` Lars Ingebrigtsen
2021-06-19 11:58 ` Lars Ingebrigtsen
2021-06-19 12:22 ` Eli Zaretskii
2021-06-19 23:15 ` Juri Linkov
[not found] ` <AM9PR09MB4977DAFB86D88A4714C1C64196A29@AM9PR09MB4977.eurprd09.prod.outlook.com>
[not found] ` <87pmt0qomh.fsf@gnus.org>
[not found] ` <AM9PR09MB4977CCFA194C77F1ADF0015C96A29@AM9PR09MB4977.eurprd09.prod.outlook.com>
2021-09-23 20:42 ` Lars Ingebrigtsen
2021-09-23 23:09 ` bug#36767: [External] : " Drew Adams
[not found] ` <AM9PR09MB49770845B0C1B7CBB331E68A96A39@AM9PR09MB4977.eurprd09.prod.outlook.com>
2021-09-23 20:52 ` Lars Ingebrigtsen
2021-09-26 9:11 ` martin rudalics
2021-09-26 9:40 ` Lars Ingebrigtsen
2021-09-26 9:55 ` Eli Zaretskii
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=54e1a2f5-62df-4bc9-a1bb-7e6c099f9c83@default \
--to=drew.adams@oracle.com \
--cc=36767@debbugs.gnu.org \
--cc=emacsuser@freemail.hu \
/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).