RE: Should nil COLLECTION element mean a "nil" candidate forcompleting-read? Alist doc.

[Drew Adams]

> >> (completing-read "ff: " '(nil ("a") ("b)))
> >
> > A nil there is simply an error.  We don't signal an error, but the
> > none of the behaviors you may see is considered as a feature.
> 
>      If COLLECTION is an alist (*note Association Lists::), the
>      permissible completions are the elements of the alist that are
>      either strings, symbols, or conses whose CAR is a string 
>      or symbol.
>      Symbols are converted to strings using `symbol-name'.  Other
>      elements of the alist are ignored. (Remember that in Emacs Lisp,
>      the elements of alists do not _have_ to be conses.)  In
>      particular, a list of strings or symbols is allowed, even though
>      we usually do not think of such lists as alists.
> 
>      -- (info "(elisp) Basic Completion")

I gotta say, this doc is poor, and on a very slippery slope (if not already
slipped to the bottom).

It's one thing to say that in Emacs Lisp a non-cons is tolerated in an alist.
More precisely, the doc says that it is not an error, but also that such
elements ARE IGNORED.

It's quite another thing to consider that alists are any lists whatsoever, that
it makes no difference what the elements are. 

A non-cons element is ignored is different from calling every list an "alist"
just because it is not an error for an alist element to be an atom. That's just
plain silly and confusing. Why have a notion of alist if every list is an alist?
Why say that atomic elements of alists are ignored if they are not?

> (But this is not really true--the first element can't be a 
> symbol other than nil (or lambda).)

Yes, indeed. There is so much undocumented special casing going on here that it
is a mine field for users. What's the point of documenting the behavior if that
doc is way off the mark and users need to discover the real behavior by trial
and error?