bug#10057: 24.0.91; doc string of `Info-find-file'

[Drew Adams]

> > 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.