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

["Drew Adams" <drew.adams@oracle.com>]

> > What does that mean? Are you simply saying "don't do that" - users
> > must ensure that there are no nil elements in the COLLECTION arg?
> 
> Yes.

Too bad.

> > And what about the rest of my post, regarding the doc 
> > contradictions and
> > confusion wrt alist elements?
> 
> Same idea:
> 
> > The doc describing the COLLECTION arg to `completing-read',
> > `try-completion', etc. does not call out this special treatment of
> > nil.  In fact, it does not even say that you can mix cons 
> > entries and string entries (let alone nil entries).
> 
> Indeed, it doesn't say you can do it.  So if you do it, you're on
> your own.

The current behavior, which you apparently don't want to correct as a bug,
contradicts the behavior descibed by the doc. The doc says that alist treatment
ignores nil entries - and here it does not. Here nil is treated as if it were
the 3-character string "nil".

That special, undocumented behavior contradicts the existing doc. Based on the
doc, users have a right to expect nil elements in alists to be ignored. There is
nothing indicating that they should expect `completing-read' to treat nil as
"nil".

We are saying one thing and doing something quite different. Users of
`completing-read' have a right to a more faithful description of its behavior.
They shouldn't have to find out by trial and error how it treats certain
elements.

I propose that this be considered a bug (not a doc bug), and that it be fixed by
doing what the doc says: ignore nil entries. That will also simplify code -
users won't need to add extra code just to filter out nil or prevent its
inclusion. Currently, not only must such code be added, but it must be
commented, since this weird behavior that it works around isn't even documented.

The status quo is not good.