emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Should nil COLLECTION element mean a "nil" candidate for completing-read


From: Drew Adams
Subject: Should nil COLLECTION element mean a "nil" candidate for completing-read? Alist doc.
Date: Mon, 20 Jul 2009 20:20:59 -0700

This change was introduced in Emacs 22. Dunno if it was deliberate. I wonder
whether it is a good change. I tend to think not, but perhaps there is some
special use case for it. In any case, if it is to be maintained, and not
considered a bug, then the doc is inadequate and confusing.

(completing-read "ff: " '(nil ("a") ("b)))
or
(completing-read "ff: " '(nil "a" "b))

The completion candidates are "nil", "a", and "b". The string "nil" is returned
if you choose that candidate (a string is always returned).

In Emacs prior to 22, the second form above was not possible, and the first form
produced only the candidates "a" and "b". That makes sense, to me.

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). It
says that the COLLECTION can be a list of strings or an alist - it is neither,
in these examples.

Not only that, the doc defining alists (Elisp manual, node Association Lists)
says that each entry is a cons - nil entries are not mentioned.

Well, after saying that the elements are conses, it says that atomic elements
don't raise an error - but they are ignored. IOW, an alist is a list of conses,
but non-conses are passed over in silence. They are certainly not treated as
actual alist elements (content) in any way.

But then the same node documents function `assoc-default' and its arg ALIST,
mentioning special treatment of atomic ALIST elements. That contradicts what is
said earlier in the same node.

If an alist is supposed to contain conses, and any non-conses are supposed to be
ignored (neither an error nor actual data), then both `completing-read' and
`assoc-default' should not speak of alist args.

In any case, besides pointing out the doc confusion, my main question is about
`completing-read': why the special treatment for nil entries (treating them as
if they were the string "nil")?






reply via email to

[Prev in Thread] Current Thread [Next in Thread]