From: Eli Zaretskii <eliz@gnu.org>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: philip@warpmail.net, theo@thornhill.no, emacs-devel@gnu.org
Subject: Re: master 1e3b0f2: Improve doc strings of project.el
Date: Sun, 12 Jul 2020 18:36:33 +0300 [thread overview]
Message-ID: <837dv8oida.fsf@gnu.org> (raw)
In-Reply-To: <5d59dd9b-0848-691a-615e-c16d2070b92d@yandex.ru> (message from Dmitry Gutov on Sun, 12 Jul 2020 18:08:50 +0300)
> Cc: theo@thornhill.no, philip@warpmail.net, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 12 Jul 2020 18:08:50 +0300
>
> If I work on parts of Emacs I'm not responsible for, I make doubly sure
> to check with authors/maintainers.
>
> How about you extend me this courtesy? I'm the author and the maintainer
> of this package.
I do. This longish and frustrating discussion is the best evidence to
that.
> >> Not documenting internal information is a valid choice.
> >
> > It isn't internal. Anyone who wants to use the return value will need
> > to understand its possible form(s).
>
> Yes, it is. Apparently you don't understand how cl-generic works.
Please drop the attitude.
> >>> But other than that, if someone needs to write code for the VC project
> >>> backend, how can they NOT rely on the form of the object that
> >>> project-try-vc returns?
> >>
> >> Nobody should "write code for the VC project backend" except its
> >> author(s).
> >
> > This is a community project, and everybody is welcome to contribute
> > code to any part of Emacs. Restricting some parts of code to a single
> > person is not a good way of ensuring Emacs's future.
>
> Not the person. The place. project-vc lives in project.el.
Irrelevant. I meant people other than the author of the code, the
person. Those others will need more detailed documentation than what
you are prepared to provide.
> Internal information can reside there without being documented, if all
> of its producers and consumers also reside there.
This is a new definition of what is "internal", and I don't agree with
it. Our accepted definition is different.
> > With respect, I disagree, having read the code and having considered
> > how I would implement something related to it. That is the single
> > most important reason why I'm trying to improve the documentation of
> > this package: to make it easier for others to expand and extend it.
>
> If you had asked me questions like "how do I implement this or that",
> none of my answers would have included the format of the return value of
> project-try-vc.
I know. Which is why I don't think your method of answering such
questions is useful enough to be used as basis for good documentation.
> > Then let's say that. But concealing the information will not solve
> > the problem, because you cannot conceal it. By not mentioning it and
> > the caveats to go with it we will be punished twice: we will make it
> > harder for people to understand the current code and contribute to it,
>
> There's nothing hard in understanding what the current code returns: you
> navigate to the function's definition and look at the end.
Documentation exists so that I won't need to follow a chain of several
functions to find the answer to a simple question. (And no, just
reading the code of project-try-vc is not enough, not unless you know
by heart what each one of the functions it calls does and returns.)
> > and we will not make sure they realize that relying on these details
> > is not a good idea.
>
> Like I said, if you're not satisfied with how that recommendation is
> conveyed, feel free to add clarifications. *Without* giving the example
> of said values in the docstrings.
I think describing the values returned by public functions is a large
part of good documentation, it clarifies quite a lot in a very
efficient way (a picture is worth a thousand words).
> >> If my method of saying "don't rely on this format" is insufficient,
> >> please go ahead and add some more clarifications on that part. But
> >> without documenting this said value format.
> >
> > You cannot usefully tell people to not rely on something without
> > describing that something.
>
> And yet, somehow, parents around the world manage to tell their children
> not to use swear words without swearing profusely themselves.
Sure, it isn't needed, not after the child him/herself swears, which
is the trigger for the parents telling them not to.
> > And there's the other disadvantage to
> > concealing information: obfuscation of the code.
>
> The code is not the issue.
Of course it is! Documentation is a significant aid in understanding
the code.
> >> If they create a new backend, they will read the code of the existing
> >> one.
> >
> > That's not how we encourage extending Emacs. Some minimal
> > documentation is needed before we can in good faith tell users to read
> > the code, and project.el currently falls short of that minimum, IMO.
>
> You seem to be criticizing something else than what I said.
I'm criticizing the "they will read the code" part.
> And I never said we don't need documentation.
I never said you did.
> Okay, internal to project.el, if we want to be more precise.
>
> > AFAICT, project-current is backend-agnostic.
>
> Except when we want to return some project instance where none were
> detected.
Which is exactly what the text I added says.
next prev parent reply other threads:[~2020-07-12 15:36 UTC|newest]
Thread overview: 149+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200619075401.21856.16524@vcs0.savannah.gnu.org>
[not found] ` <20200619075402.CE1D220A27@vcs0.savannah.gnu.org>
2020-06-19 11:01 ` master 1e3b0f2: Improve doc strings of project.el Dmitry Gutov
2020-06-19 11:24 ` Eli Zaretskii
2020-06-19 11:37 ` Basil L. Contovounesios
2020-06-19 11:50 ` Eli Zaretskii
2020-06-19 12:30 ` Dmitry Gutov
2020-06-19 12:44 ` Eli Zaretskii
2020-06-19 12:54 ` Dmitry Gutov
2020-06-19 13:27 ` Philip K.
2020-06-19 13:34 ` Dmitry Gutov
2020-06-19 14:11 ` Eli Zaretskii
2020-06-19 14:18 ` Dmitry Gutov
2020-06-19 14:24 ` Eli Zaretskii
2020-06-19 14:41 ` Philip K.
2020-06-20 7:22 ` Eli Zaretskii
2020-06-19 14:25 ` Theodor Thornhill
2020-06-19 14:37 ` Eli Zaretskii
2020-06-19 14:49 ` Dmitry Gutov
2020-06-19 15:11 ` Eli Zaretskii
2020-06-19 18:33 ` Dmitry Gutov
2020-06-19 19:01 ` Eli Zaretskii
2020-06-19 19:28 ` Dmitry Gutov
2020-06-20 6:43 ` Eli Zaretskii
2020-06-20 7:43 ` Theodor Thornhill
2020-06-20 8:55 ` Eli Zaretskii
2020-06-20 9:29 ` Theodor Thornhill
2020-06-20 10:07 ` Eli Zaretskii
2020-06-20 10:19 ` Theodor Thornhill
2020-06-20 11:37 ` Dmitry Gutov
2020-06-20 11:35 ` Dmitry Gutov
2020-06-20 12:32 ` Eli Zaretskii
2020-06-20 22:21 ` Dmitry Gutov
2020-06-20 11:29 ` Dmitry Gutov
2020-06-20 11:46 ` Kévin Le Gouguec
2020-06-20 11:57 ` Dmitry Gutov
2020-06-20 12:37 ` Eli Zaretskii
2020-06-20 21:18 ` Dmitry Gutov
2020-06-20 12:25 ` Eli Zaretskii
2020-06-20 23:17 ` Dmitry Gutov
2020-06-20 11:25 ` Dmitry Gutov
2020-06-20 12:12 ` Eli Zaretskii
2020-06-20 12:30 ` Basil L. Contovounesios
2020-06-20 12:42 ` Eli Zaretskii
2020-06-20 23:11 ` Dmitry Gutov
2020-06-21 15:08 ` Eli Zaretskii
2020-06-21 22:24 ` Juri Linkov
2020-06-22 2:27 ` Eli Zaretskii
2020-06-28 0:56 ` Dmitry Gutov
2020-06-28 14:28 ` Eli Zaretskii
2020-06-28 22:35 ` Dmitry Gutov
2020-06-29 14:50 ` Eli Zaretskii
2020-06-29 15:07 ` Stephen Leake
2020-06-29 22:35 ` Juri Linkov
2020-07-01 22:02 ` Dmitry Gutov
2020-07-01 22:07 ` Dmitry Gutov
2020-07-01 22:57 ` Dmitry Gutov
2020-07-04 7:15 ` Eli Zaretskii
2020-07-04 22:22 ` Dmitry Gutov
2020-07-05 14:26 ` Eli Zaretskii
2020-07-05 19:45 ` Dmitry Gutov
2020-07-07 15:04 ` Eli Zaretskii
2020-07-07 15:23 ` Dmitry Gutov
2020-07-10 14:27 ` Eli Zaretskii
2020-07-10 14:57 ` Dmitry Gutov
2020-07-10 18:14 ` Eli Zaretskii
2020-07-10 19:36 ` Dmitry Gutov
2020-07-11 6:58 ` Eli Zaretskii
2020-07-11 11:29 ` Dmitry Gutov
2020-07-11 12:35 ` Eli Zaretskii
2020-07-12 0:48 ` Dmitry Gutov
2020-07-12 14:00 ` Eli Zaretskii
2020-07-12 14:16 ` Dmitry Gutov
2020-07-12 14:47 ` Eli Zaretskii
2020-07-12 15:08 ` Dmitry Gutov
2020-07-12 15:36 ` Eli Zaretskii [this message]
2020-07-12 16:17 ` Eli Zaretskii
2020-07-13 1:51 ` Dmitry Gutov
2020-07-13 4:40 ` Eli Zaretskii
2020-07-13 7:11 ` Gregory Heytings via Emacs development discussions.
2020-07-13 7:21 ` Eli Zaretskii
2020-07-13 7:52 ` Gregory Heytings via Emacs development discussions.
2020-07-13 8:53 ` Eli Zaretskii
2020-07-13 18:26 ` Dmitry Gutov
2020-07-13 7:58 ` tomas
2020-07-17 10:27 ` Dmitry Gutov
2020-07-17 15:27 ` tomas
2020-07-18 0:55 ` Dmitry Gutov
2020-07-18 9:05 ` tomas
2020-07-18 10:10 ` Eli Zaretskii
2020-07-18 11:58 ` Dmitry Gutov
2020-07-18 19:14 ` Dmitry Gutov
2020-07-19 2:27 ` Richard Stallman
2020-07-19 21:59 ` Dmitry Gutov
2020-07-20 2:44 ` Richard Stallman
2020-07-13 19:51 ` Dmitry Gutov
2020-07-16 16:34 ` Eli Zaretskii
2020-07-16 18:55 ` Dmitry Gutov
2020-07-16 19:57 ` Eli Zaretskii
2020-07-16 21:02 ` Dmitry Gutov
2020-07-17 1:07 ` Richard Stallman
2020-07-17 1:30 ` Dmitry Gutov
2020-07-16 18:56 ` Dmitry Gutov
2020-07-16 19:59 ` Eli Zaretskii
2020-07-16 20:53 ` Dmitry Gutov
2020-07-13 2:51 ` Richard Stallman
2020-07-13 10:47 ` Dmitry Gutov
2020-07-13 13:00 ` Eli Zaretskii
2020-07-13 15:24 ` Dmitry Gutov
2020-07-13 16:30 ` Eli Zaretskii
2020-07-13 19:01 ` Dmitry Gutov
2020-07-13 19:41 ` Eli Zaretskii
2020-07-13 21:39 ` Dmitry Gutov
2020-07-11 12:59 ` Michael Albinus
2020-07-12 14:49 ` Dmitry Gutov
2020-07-12 17:19 ` Michael Albinus
2020-06-28 22:14 ` Dmitry Gutov
2020-06-29 14:32 ` Eli Zaretskii
2020-06-19 15:02 ` Dmitry Gutov
2020-06-19 15:13 ` Eli Zaretskii
2020-06-19 18:23 ` Dmitry Gutov
2020-06-19 18:44 ` Eli Zaretskii
2020-06-19 18:49 ` Dmitry Gutov
2020-06-19 19:07 ` Eli Zaretskii
2020-06-19 15:02 ` Theodor Thornhill via Emacs development discussions.
2020-06-19 15:19 ` Eli Zaretskii
2020-06-19 15:39 ` Theodor Thornhill
2020-06-19 17:11 ` Eli Zaretskii
2020-06-19 17:46 ` Theodor Thornhill
2020-06-19 18:03 ` Eli Zaretskii
2020-06-19 18:19 ` Dmitry Gutov
2020-06-19 18:36 ` Eli Zaretskii
2020-06-19 18:49 ` Dmitry Gutov
2020-06-19 18:22 ` Theodor Thornhill
2020-06-19 18:41 ` Eli Zaretskii
2020-06-19 18:57 ` Theodor Thornhill
2020-06-19 19:10 ` Dmitry Gutov
2020-06-19 20:08 ` theo
2020-06-19 19:04 ` Dmitry Gutov
2020-06-19 19:12 ` Eli Zaretskii
2020-06-19 19:33 ` Dmitry Gutov
2020-06-20 7:20 ` Eli Zaretskii
2020-06-20 11:41 ` Dmitry Gutov
2020-06-20 12:36 ` Eli Zaretskii
2020-06-20 21:58 ` Dmitry Gutov
2020-06-19 18:21 ` Dmitry Gutov
2020-06-19 18:30 ` Theodor Thornhill
2020-06-19 14:07 ` Eli Zaretskii
2020-06-19 14:23 ` Dmitry Gutov
2020-06-19 14:28 ` Eli Zaretskii
[not found] <<87bllfqj82.fsf@warpmail.net>
[not found] ` <<83o8pfxhzq.fsf@gnu.org>
[not found] ` <<I2nnldrvYQuQLpqgZyK7owqcMuP8kMtAdgkVXzq66i2hg6TgDaYFJe4RMj19j0J9Z1WqR9_vbifeegWNOLS3BBv-R34nJLuXYurqIVrefNE=@thornhill.no>
[not found] ` <<83imfnxgt3.fsf@gnu.org>
[not found] ` <<626efe11-0f9c-081b-11dd-0d61cee8168d@yandex.ru>
[not found] ` <<83h7v7xf7w.fsf@gnu.org>
[not found] ` <<b7f4a9ba-4320-b7b2-e150-74d667943ecd@yandex.ru>
[not found] ` <<831rmayj55.fsf@gnu.org>
[not found] ` <<6dc2c2ac-8e17-f044-dc78-8c109f936ad2@yandex.ru>
[not found] ` <<83wo42w83e.fsf@gnu.org>
[not found] ` <<6762abf5-71c1-aa54-1bac-d4c90c20870b@yandex.ru>
[not found] ` <<831rmavsuq.fsf@gnu.org>
2020-06-20 22:55 ` Drew Adams
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=837dv8oida.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=dgutov@yandex.ru \
--cc=emacs-devel@gnu.org \
--cc=philip@warpmail.net \
--cc=theo@thornhill.no \
/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).