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

[Drew Adams]

> > I forgot to point out that treating nil this way can lead to extra
> > (ugly) code, just to remove or prevent production of such 
> > nil entries,
> > so they are not available to the user.
> 
> A completion table can be a list of strings, a list of conses 
> where the car is a string, an obarry, a hashtable, or a function.
> Your "table" is none of those, so it's invalid.  Adding
> (delq nil ...)  before passing that table to the completion
> functions doesn't seem like a big issue.

First, it's not "my table". ;-)

More importantly:

1. Adding `delq' means a separate pass over the list (which can be big).
Preventing inclusion of nil, as an alternative, requires uglier, less clear code
(e.g. code that pushes an element to the list when it is non-nil).

2. Saying that users can do that as a workaround ("y'a qu'a") is a cop-out. This
is not documented - it's simply a gotcha. Users won't even know they must do
that, except through accidental discovery by trial and error (which is how I
discovered it). It is all too easy to create a list that might have some
extraneous nil elements - and not even be aware of them. Hence, this is also
error-prone.

> > IOW, I suspect that the number of times where this 
> > "feature" might be useful (for what?) is less than
> > the number of times where it is a nuisance.
> 
> It's not a feature.

Right; it's a bug - a regression wrt Emacs 21, in fact (you admit it wasn't
added intentionally, as a feature, and it is a user-visible change in behavior).
It is undocumented behavior that contradicts the documented behavior. The
general doc for alists says that nil entries will be ignored. Exceptions to that
should be documented.

You want to neither fix the code (so it will ignore nil entries) nor document
this change in behavior (since Emacs 21). That's not right.

I pose the questions: Should nil be ignored here? Should nil be treated like the
string "nil" here? Those are "should" questions. It's not sufficient to avoid a
response and take the view that the behavior is what it is and should not be
documented. I'm asking what the behavior _should_ be. And the doc should
describe what the function does - _especially_ considering any special
treatment, which is not obvious.