unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Gregory Heytings <ghe@sdf.org>
Cc: Lars Ingebrigtsen <larsi@gnus.org>, Eli Zaretskii <eliz@gnu.org>,
	emacs-devel@gnu.org
Subject: RE: master 2a7488d: Add support for displaying short documentation for function groups
Date: Mon, 12 Oct 2020 09:20:42 -0700 (PDT)	[thread overview]
Message-ID: <5657b8b2-59ee-45e8-b851-5c93da82bd82@default> (raw)
In-Reply-To: <alpine.NEB.2.22.394.2010120942150453.14620@sdf.lonestar.org>

> >> I think the manual gives superior information in most cases, so I'd
> >> really like this to link to the manual and not the doc strings.  This
> >> is also a way to guide users into the manual and read more in-depth
> >> about not just the functions described, but the machinery surrounding
> >> them, giving them more context.
> >
> > *Help* should have a link to the relevant manual node. See thread "How
> > to make Emacs popular again."  That's not hard to do, and it's been done
> > (e.g. in `help-fns+.el').
> >
> 
> As I already explained repeatedly, this is _not_ the meaning of my
> proposal in that thread.

The thread is not only about your posts to it.

> My proposal is to _manually_ add pointers to the
> relevant manual _chapters_ in docstrings.

Yes, and I've voiced no objection to that.  I was the
one who pointed you to an example where we do that
already.

But you also said that you think we cannot provide
such links automatically.  And my response to that
is that we can.  And I have.  (And so have others.)
We can use that code, or we can use different code.

We can do both: we can have manual fiddling to add
links override/replace/augment any programmatically
provided links, when that's helpful.

So far, we have _VERY_ few manually provided links.
Nothing is stopping someone from proposing adding
this or that link manually.  Still, we have very
few, so far.

Today, you can use `C-h k C-h m' to get the *Help*
for `describe-mode', then click its `manuals' link:

  For more information see the manuals.

That gives you an Info Index buffer with two links:

  Index Matches
  *************

  Index entries that match `describe-mode':

  * Menu:

  * describe-mode [elisp]:   (elisp)Mode Help. (line 11)
  * describe-mode [emacs]:   (emacs)Misc Help. (line 36)

And those take you to these nodes, which provide the
doc for `describe-mode':

1. (emacs) Top > Help > Misc Help
2. (elisp) Top > Modes > Major Modes > Mode Help

> For example, the docstring of kill-buffer would
> have two links, one to (info "(emacs)Buffers") and another one to (info
> "(elisp)Buffers"), with some explanation.  For example:
> 
> See also the following manual chapters: for interactive use, see `(emacs)
> Buffers'; for Emacs Lisp programming use, see `(elisp) Buffers'.

And for `kill-buffer' the `manuals' link gives you
an Info Index buffer with these two links:

 * kill-buffer [elisp]:   (elisp)Killing Buffers. (line 31)
 * kill-buffer [emacs]:   (emacs)Kill Buffer. (line 22)

I think those are more appropriate targets than your
`Buffers' nodes.  But nothing prevents us from using
code that does what you prefer, if that's agreed upon.
It's not hard to get to the "chapter" node for a node
that the Index takes us to.

But there's a good reason why the Index entries for
`kill-buffer' take us to the nodes they do: they're
specifically about _that command_.

> Your proposal is to merge a feature of help-fns+.el in help-fns.el.  This
> feature adds a link in *Help* buffers, and when the user clicks on that
> link the indexes of a (user chosen) list of manuals are checked to see if
> they contain pointers to the subject of the *Help* buffer.  Doing this is,
> as you said yourself, inefficient.  The result of this scan is presented
> in another buffer as a list of links, and when the user clicks on these
> links the place where the subject of the *Help* buffer is documented in
> the manual is displayed.
> 
> These are two very different proposals.

They're different, yes, but not profoundly different.

And the inefficiency I referred to is likely from my
insufficient knowledge of using `info-lookup'.

With my code EITHER you can quickly get a direct link
to one of the manuals (that's what `info-lookup-symbols'
gives you), OR you can get a link that when clicked
looks up the symbol in each of the manuals and gives
you an Index list of links, as described above.  It's
a user choice.

The former is immediate, but it doesn't give you
links to each of the relevant manuals.  The latter
takes the time to perform index lookups.

But I'm sure that someone more familiar with the
`info-lookup' code can do better than I, providing
links to multiple manuals quickly.  And if that
possibility isn't yet available from info-lookup,
it can likely be coded.

My point is not that we need to use the `help-fns+.el'
code.  And it's not to exclude the addition of links
manually.

My point is that we can and should provide links to
the manuals from *Help*, and we can start doing that
today.  Improvements are always possible.



  reply	other threads:[~2020-10-12 16:20 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20201011035127.7723.3256@vcs0.savannah.gnu.org>
     [not found] ` <20201011035128.E3FD320667@vcs0.savannah.gnu.org>
2020-10-11  3:55   ` master 2a7488d: Add support for displaying short documentation for function groups Lars Ingebrigtsen
2020-10-11 13:49     ` Eli Zaretskii
2020-10-11 21:47       ` Lars Ingebrigtsen
2020-10-11 23:38         ` Drew Adams
2020-10-12  8:05           ` Gregory Heytings via Emacs development discussions.
2020-10-12 16:20             ` Drew Adams [this message]
2020-10-12 16:50               ` Gregory Heytings via Emacs development discussions.
2020-10-12 17:29                 ` Drew Adams
2020-10-13 20:05     ` Juri Linkov
2020-10-13 20:35       ` Drew Adams
2020-10-14  7:48         ` Juri Linkov
2020-10-13 20:55       ` T.V Raman
2020-10-14  7:52         ` Juri Linkov
2020-10-14 14:41           ` T.V Raman
2020-10-14  4:12       ` Lars Ingebrigtsen
2020-10-14  7:59         ` Juri Linkov
2020-10-15  6:43           ` Lars Ingebrigtsen
2020-10-15 12:24             ` Stefan Monnier
2020-10-18 20:12               ` Juri Linkov
2020-10-19  3:47                 ` Richard Stallman
2020-10-19  8:05                   ` Juri Linkov
2020-10-23 20:24     ` Stefan Kangas
2020-10-24 19:59       ` Lars Ingebrigtsen
2020-10-24 23:51         ` Stefan Kangas
2020-10-25 13:04           ` Lars Ingebrigtsen
2020-10-27 13:48       ` Basil L. Contovounesios
2020-10-27 14:33         ` Stefan Kangas
2020-10-27 15:43           ` Basil L. Contovounesios
2020-10-27 17:33             ` Lars Ingebrigtsen
2020-10-27 22:02               ` Stefan Kangas
2020-10-28  8:20                 ` Mattias Engdegård
2020-10-28 13:50                   ` Stefan Kangas
2020-10-28 11:04                 ` Lars Ingebrigtsen
     [not found]   ` <CADwFkmnXuyh2cAddLtgTNmsSv8av3o9qk98CVcTAzq6B8Lrpkw@mail.gmail.com>
     [not found]     ` <87blgknjze.fsf@gnus.org>
2020-10-30 11:58       ` Stefan Kangas
2020-10-30 12:05         ` Lars Ingebrigtsen
2020-10-30 12:27           ` Stefan Kangas

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=5657b8b2-59ee-45e8-b851-5c93da82bd82@default \
    --to=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=ghe@sdf.org \
    --cc=larsi@gnus.org \
    /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).