From: Drew Adams <drew.adams@oracle.com>
To: Dmitry Gutov <dgutov@yandex.ru>, Eli Zaretskii <eliz@gnu.org>
Cc: stephen_leake@stephe-leake.org, emacs-devel@gnu.org
Subject: RE: docstrings and elisp reference
Date: Sat, 17 Jun 2017 07:52:47 -0700 (PDT) [thread overview]
Message-ID: <89a80425-0c56-48aa-a124-b4ded2f41989@default> (raw)
In-Reply-To: <8241d6cf-0902-5f3b-9060-8bb445c02fed@yandex.ru>
> > The original proposal was for a literal copying of the same
> > text. Drew was talking about duplicating the information,
> > but expressed in a different, sometimes very different, form.
>
> And my problem is that it's very often expressed in a very
> similar form, if not copied verbatim.
What is your problem with such similarity? That it is only
sometimes similar and not always identical? That it is at
all similar and not totally different?
Sometimes there is no need for the presentation to be very
different; sometimes a difference makes sense.
And nothing says that every existing doc string is perfect.
Those that are apparently problematic to you, because
similar, might well be candidates for improvement. Their
being "very similar" might be wholly appropriate, or it
might just represent inattention or laziness.
You seem to be missing the point that manual and doc string
can have different uses and purposes. You seem to think
that when they differ that's a waste, and when they are the
same that's a waste because the text could have been reused
automatically.
Look not at the similarity or difference of this or that
function description. Think about the difference in how
the two can be used. It is _that_ difference that informs
possible differences or similarities of text.
A written news article is not a video clip. Both might
tell the same story, in part or in whole, but they might
well tell it differently. Same or similar message; but
often different delivery/presentation.
> > This doesn't really resolve the issue pointed out by Drew.
> > And that is only one of the issues, there are others, also
> > valid ones.
>
> Drew said docstrings are mostly for the interactive case.
No. I never said any such thing. You are either
misreading or misrepresenting.
I said:
The presentation and context of use are different.
The level of detail is often different. (Sometimes
there is more detail in the manual; sometimes there
is more in a doc string.)
In particular, doc strings are written as user help.
The interactive use, if any, is typically described
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
first, and from the point of an interactive user.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Not so, the Elisp manual.
That says nothing about doc strings being "mostly for
the interactive case." It says that a doc string about
a _command_ presents the command _first_ in its use as
a command, that is, interactively.
> That's wildly inaccurate:
It's wildly inaccurate for you to say that "Drew said
docstrings are mostly for the interactive case."
> as an Elisp programmer, I almost always look at the
> docstrings and comments, but very rarely at the manuals.
> Many others do the same.
We all look at doc strings. And many of us look at
comments - and the code that is commented. Doc strings
are typically the most immediate help for users - and
that includes Lisp programmers.
Doc strings are not only, or even primarily, "for the
interactive case". Doc strings are not manuals, and
manuals are not doc strings - that's all. They have
purposes that can be different but can overlap.
Doc strings are user help, including but not limited
to help for non-Lisp users. Interactive use of a
command is described first in a doc string because the
main purpose of a command is to be used interactively.
Hard to believe this is not obvious to us all, by now.
Video is not newsprint. A song is not a painting.
A garden is not an essay.
But perhaps it is not obvious to you because, as you
say, you "very rarely" consult the manuals? If doc
strings and comments suffice for you, then why worry
about this question at all?
Is it just because _you_ don't want to be bothered
maintaining the manual? If so, and if you feel that
strongly, then don't bother. Someone else will do
it - or it won't get done. Either way, you need not
get bothered by it, if that's your problem.
> my problem is that it's very often expressed in
> a very similar form, if not copied verbatim.
Don't worry.
Emacs has always put importance on its manuals, as
well as its doc strings. I hope it will long
continue to do so, whoever participates in developing
and maintaining it.
But sure, there have always been those participants
who are more, and others who are less, concerned about
doc/help, including comments, doc strings, and manuals.
Nothing says that each contributor needs to be equally
interested in every possible way of contributing.
What's wrong is to mistake one's own interests, which
are typically limited (parochial), for the broader
interests of Emacs as a whole. Just because you might
rarely read the manuals, that's not a reason for Emacs
to drop development of manuals or reduce their quality.
next prev parent reply other threads:[~2017-06-17 14:52 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
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 [this message]
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=89a80425-0c56-48aa-a124-b4ded2f41989@default \
--to=drew.adams@oracle.com \
--cc=dgutov@yandex.ru \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=stephen_leake@stephe-leake.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).