unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Basil L. Contovounesios" <contovob@tcd.ie>
To: <35163@debbugs.gnu.org>
Subject: bug#35163: 25.1; `narrow-to-region' docstring no mention of args
Date: Tue, 09 Apr 2019 02:13:17 +0100	[thread overview]
Message-ID: <87h8b89e1e.fsf@tcd.ie> (raw)
In-Reply-To: <86zhp0t26p.fsf@zoho.eu> (Emanuel Berg's message of "Tue, 09 Apr 2019 03:09:02 +0200")

Emanuel Berg <moasenwood@zoho.eu> writes:

> Basil L. Contovounesios wrote:
>
>> [ Your Mail-Followup-To and Mail-Copies-To
>>   headers seem wrong, they should point to
>>   the bug address 35163@debbugs.gnu.org
>>   instead of bug-gnu-emacs@gnu.org. ]
>
> [ OK, now I reply tho this (i.e., your) message
>   thru gmane.emacs.bugs, and after that, I hope
>   to reply to Noam Postavsky's message, and
>   I'll do that thru mail, and we'll perhaps see
>   if there is a difference or both ways are
>   broken. My hunch is it'll work if I use mail,
>   but not if I use the Gmane newsgroup. ]
>
> [ I was right, the Gmane newsgroups is to
>   blame. So I re-send it here as well.
>   Now everyone should be happy and content. ]

Indeed, your reply to Noam correctly kept the bug report CCed, whereas
your previous reply to me did not.

>> They're conventions and decent guidelines for
>> the general case, not rules. Humans reserve
>> the right to exercise their own judgement.
>> In particular, the "rule" to mention
>> positional arguments in the order they appear
>> often makes for unreadable docstrings IME.
>
> OK, the rule to mention them in order makes
> sense especially if you have a function with
> tons of args. But most important is that they
> are mentioned exactly as they are, so they can
> be searched for. Often, in Elisp code, you see
> this
>
>
>     (some-function some-feature some-property t)
>
>
> Now, you can often guess what everything does,
> except for the last `t'. Brining up the help
> and searching for the arg's name to find it
> immediately in the docstring is a good way of
> finding out, fast.

I think most of us agree that docstrings, especially those of public
functions, should mention their accepted arguments by name, if not in
the exact same order as they appear in the argument list.  Eli fixed
this for narrow-to-region[1] following your report.

[1: a5da653319]: * src/editfns.c (Fnarrow_to_region): Doc fix.  (Bug#35163)
  2019-04-08 19:53:48 +0300
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a5da653319a3018074debfc7b4fdd90ac7ea838c

>> Eli [...] keeps himself very busy
>> co-maintaining Emacs, yet he still manages to
>> set a stellar example of how documentation
>> should be maintained.
>
> ... okay? I just thought that was a strange
> statement. Like someone had _denied_ that (?)

No-one denied that.  You said:

> Should I interpret this as "one shouldn't
> bother the maintainers with details like this"?

So my sentence was intended as an example of how un-bothered maintainers
are by details like this, in that e.g. Eli pays a lot of attention to
documenting things properly, and following Emacs and GNU conventions.

All I meant to say is that these documentation details aren't beneath
anyone.  I hope I've managed to explain myself properly.

Thanks,

-- 
Basil





  reply	other threads:[~2019-04-09  1:13 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-05 18:51 bug#35163: 25.1; `narrow-to-region' docstring no mention of args Emanuel Berg
2019-04-05 19:08 ` Eli Zaretskii
2019-04-05 19:26   ` Emanuel Berg
2019-04-06  6:25     ` Eli Zaretskii
2019-04-06  7:10       ` Emanuel Berg
2019-04-06  9:01         ` Eli Zaretskii
2019-04-06 14:32           ` Emanuel Berg
2019-04-08 16:24           ` Glenn Morris
2019-04-08 16:55             ` Eli Zaretskii
2019-04-08 21:14             ` Emanuel Berg
2019-04-08 22:19               ` Basil L. Contovounesios
2019-04-09  0:45                 ` Emanuel Berg
2019-04-09  1:09                 ` Emanuel Berg
2019-04-09  1:13                   ` Basil L. Contovounesios [this message]
2019-04-09  8:53                     ` Emanuel Berg
2019-04-09  9:37                       ` Robert Pluim
2019-04-09  9:55                         ` Emanuel Berg
2019-04-09 11:42                           ` Robert Pluim
2019-04-09 12:48                             ` Emanuel Berg
2019-04-11  9:46                               ` Robert Pluim
2019-04-12  5:27                                 ` Emanuel Berg
2019-04-09  6:54                 ` Eli Zaretskii
     [not found] ` <handler.35163.D35163.155474252232285.notifdone@debbugs.gnu.org>
2019-04-08 23:09   ` Noam Postavsky
2019-04-09  0:48     ` Emanuel Berg
2019-04-09  7:08       ` Eli Zaretskii
2019-04-09  6:56     ` 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=87h8b89e1e.fsf@tcd.ie \
    --to=contovob@tcd.ie \
    --cc=35163@debbugs.gnu.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).