bug#42871: 28.0.50; Documentation for `seq-contains-p` is outdated

[Basil L. Contovounesios]

Iwan in 't Groen <iwanintgroen@gmail.com> writes:

> The return value in the description of this function (now a predicate) should 
> also be changed.
>
> Currently is says:
> This function returns non-‘nil’ if at least one element in SEQUENCE is equal 
> to ELT.
>
> It should be:
> This function returns ’t’ if at least one element in SEQUENCE is equal to ELT.
>
> diff --git a/doc/lispref/sequences.texi b/doc/lispref/sequences.texi
> index ca52369bd0..bb80307c8c 100644
> --- a/doc/lispref/sequences.texi
> +++ b/doc/lispref/sequences.texi
> @@ -784,7 +784,7 @@ Sequence Functions
>  
>  
>  @defun seq-contains-p sequence elt &optional function
> -  This function returns non-@code{nil} if at least one element in
> +  This function returns @code{t} if at least one element in
>  @var{sequence} is equal to @var{elt}.  If the optional argument
>  @var{function} is non-@code{nil}, it is a function of two arguments to
>  use instead of the default @code{equal}.

I don't feel strongly about this, but note that in general it's common
and fine to say non-nil in place of t, even when the value is t.
Predicates are allowed to return other non-nil values too, see
e.g. proper-list-p.  The only time the distinction matters enough to
document it is when different non-nil values have different meanings,
e.g. with while-no-input or with certain user options.

HTH,

-- 
Basil