[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should nil COLLECTION element mean a "nil" candidate for completing-
Re: Should nil COLLECTION element mean a "nil" candidate for completing-read? Alist doc.
Mon, 27 Jul 2009 22:26:49 -0600
Thunderbird 184.108.40.206 (Macintosh/20090605)
Drew Adams wrote:
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
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".
The doc string and the info entry cited by Johan do not agree: the info
entry mentions the possibility of symbol elements. And of course `nil'
is a symbol whose name is "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
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
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.
Denver, Colorado, USA
Re: Should nil COLLECTION element mean a "nil" candidate for completing-read? Alist doc., Johan Bockgård, 2009/07/21