unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
Subject: RE: docstrings and elisp reference
Date: Wed, 7 Jun 2017 07:18:47 -0700 (PDT)	[thread overview]
Message-ID: <ea8e6bd5-ed05-4098-8599-a11910386271@default> (raw)
In-Reply-To: <jwv60g87y6p.fsf-monnier+gmane.emacs.devel@gnu.org>

> - Better integration between the manual browser and the docstring
>   browser, so you can click on a function/variable name in the manual to
>   get to its docstring and you can easily jump from a docstring to the
>   relevant section of the manual.

Yes, 100%.  I've long argued that.  Cross-reference, not text reuse.

And Emacs has already come a fair distance in that direction.  It
could still be improved.

> - Remove the redundant var/fun documentation from the manual (this is
>   a tedious job: there is some redundance but it's not systematic, so
>   we can't just do this removal systematically).

We should not remove redundant _information_, if there is a
reason that it will help readers.  And that's the case for 99.9%
of the var/fun presentations in the manual.  There is often a
discussion about whether a given var/fun should be explicitly
doc'd in the manual - it's a judgment call.  It's not because
we _can_ add the doc for a var/fun to the manual that we should.

Think redundancy NOT for maintainers (I'm not saying you did that)
but for readers.

A reader should be _able_ to click to go to additional info
or to a different presentation/orientation of the same material.

But it is important, IMO, for the manual to have the information
that it has, even when that means that the same information is
provided also elsewhere (e.g. in a doc string).  We lose, do not
gain, if we decide to remove the doc for a given function etc.
from the manual just because it has a doc string - or vice versa.

The question of redundancy _for the user_ means that we also do
not, in general, want to have exactly the same text in doc string
and manual.  A user does not want to click a function name in one
or the other, only to end up seeing exactly the same text in the
other location.

"Reuse" for readers is generally a negative - it means reading
the same thing again, generally without being forewarned.
Little is more frustrating for a reader.  ("Why did you send me
here?  This is the same text!")

That is not to say that repetition in doc is always negative.
Far from it.  It's about judgment: repeat when there is a good
(e.g. pedagogical) reason to repeat.

> - Come up with a way to re-add those var/fun documentation into the
>   printed manual (e.g. by adding to the Texinfo source external
>   references to docstrings, which are then processed by now ad-hoc
>   script).

Not a good idea, IMO.  See above.



  parent reply	other threads:[~2017-06-07 14:18 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-05 21:26 docstrings and elisp reference Jean-Christophe Helary
2017-06-06  0:09 ` Tino Calancha
2017-06-06  5:10   ` Jean-Christophe Helary
2017-06-06 15:03     ` Eli Zaretskii
2017-06-06 20:25       ` Stephen Leake
2017-06-06 20:36         ` Drew Adams
2017-06-08  2:29           ` Etienne Prud’homme
2017-06-08  3:48             ` Jean-Christophe Helary
2017-06-08  5:39               ` Chad Brown
2017-06-08  8:12                 ` Jean-Christophe Helary
2017-06-08 15:11                   ` Eli Zaretskii
2017-06-08 15:42                     ` Jean-Christophe Helary
2017-06-09  0:25                       ` Chad Brown
2017-06-08 18:29               ` Etienne Prud’homme
2017-06-09  4:10               ` Richard Stallman
2017-06-08 15:18             ` Eli Zaretskii
2017-06-08 18:10               ` Etienne Prud’homme
2017-06-08 19:14                 ` Eli Zaretskii
2017-06-08 20:07                   ` Drew Adams
2017-06-08 20:22                   ` Etienne Prud’homme
2017-06-08 22:44                     ` Jean-Christophe Helary
2017-06-09  4:10             ` Richard Stallman
2017-06-09  5:20               ` Etienne Prud’homme
2017-06-09  7:08                 ` Eli Zaretskii
2017-06-09  8:27                   ` Yuri Khan
2017-06-09  9:38                     ` Eli Zaretskii
2017-06-09 12:21                       ` Eli Zaretskii
2017-06-09 12:32                         ` Yuri Khan
2017-06-09 13:46                           ` Eli Zaretskii
2017-06-09 19:24                             ` Etienne Prud’homme
2017-06-10  1:06                               ` Jean-Christophe Helary
2017-06-10 11:36                                 ` Nikolay Kudryavtsev
2017-06-10 14:26                                   ` Drew Adams
2017-06-10  3:19                 ` Richard Stallman
2017-06-10  7:31                   ` Eli Zaretskii
2017-06-11  2:43                     ` Richard Stallman
2017-06-11  2:44                     ` Richard Stallman
2017-06-11 15:18                       ` Stefan Monnier
2017-06-12  2:52                         ` Richard Stallman
2017-06-12  3:27                           ` Stefan Monnier
2017-06-13  3:25                             ` Richard Stallman
2017-06-10  8:22                   ` Yuri Khan
2017-06-10  3:19                 ` Richard Stallman
2017-06-06 20:45         ` Joost Kremers
2017-06-07 13:03           ` Stefan Monnier
2017-06-07 13:23             ` Yuri Khan
2017-06-07 13:31               ` Stefan Monnier
2017-06-07 14:18             ` Drew Adams [this message]
2017-06-07 15:43             ` Eli Zaretskii
2017-06-06 20:47         ` Dmitry Gutov
2017-06-06 21:21           ` Drew Adams
2017-06-06 21:50             ` Dmitry Gutov
2017-06-07  5:28               ` Eli Zaretskii
2017-06-17 12:46                 ` Dmitry Gutov
2017-06-17 13:04                   ` Alan Mackenzie
2017-06-17 13:55                     ` Dmitry Gutov
2017-06-17 20:14                       ` Alan Mackenzie
2017-06-18  2:32                         ` Eli Zaretskii
2017-06-18 19:52                           ` Richard Stallman
2017-06-17 22:13                     ` Richard Stallman
2017-06-20 18:05                     ` John Wiegley
2017-06-17 14:10                   ` Eli Zaretskii
2017-06-17 15:13                     ` Stefan Monnier
2017-06-17 18:59                     ` Paul Eggert
2017-06-17 14:52                   ` Drew Adams
2017-06-19 18:31                     ` Thien-Thi Nguyen
2017-06-07 14:05               ` Drew Adams
2017-06-07 14:27                 ` Drew Adams
2017-06-08  1:27           ` Richard Stallman
2017-06-06 22:42 ` Richard Stallman
2017-06-06 22:49   ` Dmitry Gutov
2017-06-07  5:20     ` 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=ea8e6bd5-ed05-4098-8599-a11910386271@default \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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).