RE: master 2bb0703 1/2: lisp/*.el: Force non-nil result to t, to match docstring

[Drew Adams]

> > > Depends. When the function is a predicate, t/nil makes more sense
> > > (generally speaking, there are exceptions) that non-nil/nil.
> >
> > I thought it was kinda opposite: When it's a predicate, we only care
> > about nil/non-nil.
> 
> No, predicate returns a boolean result.  Recall the recent discussion
> of using -p in function and variable names.

That begs the question of what "boolean result"
means.  Is the number 42 or the string "Bernie"
or "false" a Boolean value (true), or not?

In Lisp, in general (e.g., other than Scheme),
Boolean values include so-called "generalized
booleans", which means nil (for false) and
any non-nil value (for true).

That some particular function (predicate) might
want to always return t as the non-nil value to
indicate true is up to that function, and if
the fact that it does so is important to its
behavior then it should be documented that it
does so.

If there's no good reason for a predicate to
return something other than t to represent
true, then it should typically just use t.

But in general there should be no requirement
for a predicate to return t for true.  Any
non-nil value means true, a priori.

I agree with this general and longstanding
Lisp convention.  So +1 for not, in general
depending on t to be the only true value.

So IIUC, I agree with Lars on this general
question.

There's nothing wrong with a predicate always
returning only t for true, of course.  That
doesn't affect how other predicates handle
generalized Boolean values.  t is non-nil,
after all, even if non-nil is not necessarily
t.

(Not saying anything about whether this or
that particular predicate is better "fixed"
by ensuring that it uses only t for true or
changing its doc to say that t is the only
true value.  Not saying anything about the
"fixes" Juanma made.)

Node (elisp) `nil and t' says it very well:

 In contexts where a truth value is expected,
 any non-'nil' value is considered to be TRUE.

 However, 't' is the preferred way to represent
 the truth value TRUE.  When you need to choose
 a value that represents TRUE, and there is no
 other basis for choosing, use 't'.  The symbol
 't' always has the value 't'.

I agree with every bit of that text.

If there is no good reason not to use t, use t.
But something TESTING a value as a truth value
should, in general, consider any non-nil value
to be true.

("In general", because sometimes the value to
test can be either a truth value or something
else.  In such a case, different non-nil values
can mean different things.)

And there is often a good reason for a given
predicate to return some other non-nil value
than t for true.  Why is this true so often?
Because it lets the predicate be, secondarily,
more than a predicate, returning secondary
information along with truth value t. 

Common Lisp is also a good reference in this
regard.  "In Common Lisp, as in most Lisp
dialects..."

https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node9.html

http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_g.htm