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

[Memnon Anon <gegendosenfleisch@googlemail.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> You apparently want a non-nil, non-t value to implicitly be considered
>> unpredictable and unsupported ("you're on your own"), for the benefit
>> of "future compatibility", and you apparently do not want to tell
>> users that explicitly.  So be it.
>
> Saying this explicitly everywhere we rely on it would be silly.
> It's a general rule that applies to all software I know.

,----[ (info "(elisp)Documentation Tips") ]
|    * The documentation string for a variable that is a yes-or-no flag
|      should start with words such as "Non-nil means," to make it clear
!      that all non-`nil' values are equivalent and indicate explicitly
|      what `nil' and non-`nil' mean.
`----

How is this so much different?

The function checks for '(if noerror ...' , so "non-nil" matches what the
function actually does more precisely.

Future compatibility? The sentence in the docstring dates back to 2004,
for all versions since then, the test was always '(if noerror ...'.

When is this future to come?

If there were plans to differentiate 't' from other non-nil values, I 
think they got lost :). And it's not like the file is under heavy
development and an ever moving target, anyways ...

Whatever, this teeny tiny issue got way more attention than it deserved
in the first place I guess, so ... I'll stop now ;)

Memnon