unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Eli Zaretskii'" <eliz@gnu.org>
Cc: 10057@debbugs.gnu.org
Subject: bug#10057: 24.0.91; doc string of `Info-find-file'
Date: Wed, 16 Nov 2011 06:52:29 -0800	[thread overview]
Message-ID: <E03D51D3CE5A43EEB0CCA67E83E89AAC@us.oracle.com> (raw)
In-Reply-To: <E1RQawy-0000oP-4j@fencepost.gnu.org>

> > Apparently, we should not bother to point out when 
> > parameters to functions etc. are undefined/undescribed.
> 
> No.  "We" should of course report such potential omissions,

Not according to Stefan's "general rule": According to that, omission indicates
clearly to everyone that that the behavior is unpredictable and unsupported.

> but when told that the maintainers don't want to spell that out
> in the doc, "we" should accept their judgment,

What judgment not to spell it out?  Was the bug classified won't-fix? wishlist?
not-a-bug?  Nope, not yet.  There was some disagreement and discussion about
what the doc omission might mean to readers, but there was also: Send a patch.
If someone wants to install, OK.  Install it yourself.

> instead of raising the level of flames and continuing the argument.

It was not I who made a mountain out of this tiny molehill of a bug.  It was a
trivial `t' -> `non-nil' substitution to make things clear.  Do it or don't do
it - your choice.

To me, making that change should be a no-brainer, but the suggestion
nevertheless engendered quite a lot of flak.  Including some that had nothing to
do with this bug in particular or even such doc omissions in general - ad
hominem comment about my participation in bug reporting and fixing bugs.

AFAICT, there was no decision not to make that change, and no decision to make
it.  There was discussion about what the omission (and such omissions generall)
can mean for readers.

And yes, there were some flames ("fun") - about my degree of involvement in
fixing bugs etc.  My end of the discussion has been limited to what it is we
want to tell users, and the effects that incomplete info can have (confuse
readers, make them wonder).

I've been clear that the choice about this proposed change is Stefan's to make,
obviously.  I have no problem with accepting whatever "judgment" might come.
Bug reporters only raise a question; the maintainers answer it: fix/won't fix
etc.






  reply	other threads:[~2011-11-16 14:52 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-15 20:30 bug#10057: 24.0.91; doc string of `Info-find-file' Drew Adams
2011-11-15 21:39 ` Juri Linkov
2011-11-15 21:56   ` Drew Adams
2011-11-15 22:17     ` Andreas Schwab
2011-11-15 22:21       ` Drew Adams
2011-11-15 21:50 ` Stefan Monnier
2011-11-15 22:08   ` Drew Adams
2011-11-16  2:28     ` Stefan Monnier
2011-11-16  2:29     ` Stefan Monnier
2011-11-16  3:05       ` Drew Adams
2011-11-16  3:24         ` Glenn Morris
2011-11-16  5:23           ` Drew Adams
2011-11-16  4:22         ` Stefan Monnier
2011-11-16  5:24           ` Drew Adams
2011-11-16  8:34             ` Eli Zaretskii
2011-11-16 14:52               ` Drew Adams [this message]
2011-11-16 18:10                 ` Eli Zaretskii
2011-11-16 18:29                   ` Drew Adams
2011-11-16 18:43           ` Memnon Anon
2011-11-16 19:56             ` Eli Zaretskii
2011-11-16 17:03         ` Juri Linkov
2011-11-16 18:29           ` Drew Adams
2011-11-16 19:31             ` Juri Linkov
2011-11-16 20:04               ` Drew Adams
2011-11-16 20:28                 ` Juri Linkov

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=E03D51D3CE5A43EEB0CCA67E83E89AAC@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=10057@debbugs.gnu.org \
    --cc=eliz@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).