all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jonas Bernoulli via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: stefankangas@gmail.com, 72357@debbugs.gnu.org
Subject: bug#72357: Checkdoc fixes in transient.el
Date: Mon, 29 Jul 2024 23:56:00 +0200	[thread overview]
Message-ID: <87a5hzn9qn.fsf@bernoul.li> (raw)

Hello Stefan,

I don't think your commit e3bba63ecb9 is an improvement.

I generally agree that the first line of a docstring should be a short
sentence, and that no other sentence should start on that line, even if
there is plenty of space left.  In fact I have contributed many similar
fixes to package maintained by other people.

However, I would argue that the usual reasoning for why one should do
that, does not apply here.  In this case, the first line won't appear
anywhere by itself, without the rest of this docstring (such as in
apropos output), because this is a method not a "regular" or generic
function.

Looking at, for example, "C-h f transient-format-description", I feel
that it would not make sense if all the methods themselves began with a
summary line.  Only the overall generic function *needs* a summary line.
In some case it may make sense to give individual methods their own
summary lines, but for very short, one paragraph method docstrings this
should not be a requirements.  When a method is so simple that it can be
described using a single short paragraph (but not a single sentence,
which can fit on a single line), then that should be possible, without
being forced to mess up the justification of that paragraph.

IMO checkdoc should be updated to not enforce the conventions, which
were designed for "top-level" functions (and variables) on methods
as well.

Also consider the case where a method can be described using a single
sentence, but that sentence requires two lines.  Forcing the author
to prefix that short paragraph with a sorter sentence, which only
serves to satisfies an ill-applied convention, feels wrong to me.

---

In this particular case, separating the first sentence from the rest of
the paragraph (but without completely rewording the paragraph) is a step
backward.

Each of these method docstrings consist of two sentences.  The first
sentence is very much not a summary of the second sentence.  Each of
these methods does two things and each thing is described using one
sentence.  The important thing, the one that makes the method useful, is
described in the second sentence.  The boring thing (call the next
method) is described in the first sentence, because it is done first.
Using the first sentence as the "summary" is wrong in these cases.
Changing the order in which the two steps are described, would likely
lead to awkward wording.

     Jonas





             reply	other threads:[~2024-07-29 21:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-29 21:56 Jonas Bernoulli via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-07-30 11:39 ` bug#72357: Checkdoc fixes in transient.el Eli Zaretskii
2024-09-14 13:40 ` 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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a5hzn9qn.fsf@bernoul.li \
    --to=bug-gnu-emacs@gnu.org \
    --cc=72357@debbugs.gnu.org \
    --cc=jonas@bernoul.li \
    --cc=stefankangas@gmail.com \
    /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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.