all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Should nil COLLECTION element mean a "nil" candidate for completing-read? Alist doc.
@ 2009-07-21  3:20 Drew Adams
  2009-07-21  3:40 ` Should nil COLLECTION element mean a "nil" candidate forcompleting-read? " Drew Adams
  2009-07-21 13:23 ` Should nil COLLECTION element mean a "nil" candidate for completing-read? " Stefan Monnier
  0 siblings, 2 replies; 13+ messages in thread
From: Drew Adams @ 2009-07-21  3:20 UTC (permalink / raw)
  To: emacs-devel

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")?






^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2009-07-28  4:26 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-21  3:20 Should nil COLLECTION element mean a "nil" candidate for completing-read? Alist doc Drew Adams
2009-07-21  3:40 ` Should nil COLLECTION element mean a "nil" candidate forcompleting-read? " Drew Adams
2009-07-21 15:48   ` Stefan Monnier
2009-07-22  0:07     ` Should nil COLLECTION element mean a "nil" candidateforcompleting-read? " Drew Adams
2009-07-22  3:15       ` Stefan Monnier
2009-07-21 13:23 ` Should nil COLLECTION element mean a "nil" candidate for completing-read? " Stefan Monnier
2009-07-21 14:51   ` Drew Adams
2009-07-21 15:55     ` Stefan Monnier
2009-07-22  0:07       ` Drew Adams
2009-07-22  3:24         ` Stefan Monnier
2009-07-28  4:26         ` Kevin Rodgers
2009-07-21 23:22   ` Johan Bockgård
2009-07-22  0:07     ` Should nil COLLECTION element mean a "nil" candidate forcompleting-read? " Drew Adams

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.