From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: Should nil COLLECTION element mean a "nil" candidate for completing-read? Alist doc. Date: Mon, 20 Jul 2009 20:20:59 -0700 Message-ID: <5721FBADB175440B9BA3383934E0AC30@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1248146485 27539 80.91.229.12 (21 Jul 2009 03:21:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Jul 2009 03:21:25 +0000 (UTC) To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 21 05:21:18 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MT5un-0007Ka-B5 for ged-emacs-devel@m.gmane.org; Tue, 21 Jul 2009 05:21:17 +0200 Original-Received: from localhost ([127.0.0.1]:47808 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MT5um-0000hH-JN for ged-emacs-devel@m.gmane.org; Mon, 20 Jul 2009 23:21:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MT5uh-0000el-GD for emacs-devel@gnu.org; Mon, 20 Jul 2009 23:21:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MT5uc-0000VH-Qp for emacs-devel@gnu.org; Mon, 20 Jul 2009 23:21:10 -0400 Original-Received: from [199.232.76.173] (port=38182 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MT5uc-0000V8-G8 for emacs-devel@gnu.org; Mon, 20 Jul 2009 23:21:06 -0400 Original-Received: from rcsinet12.oracle.com ([148.87.113.124]:42504 helo=rgminet12.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MT5uc-0001pg-3c for emacs-devel@gnu.org; Mon, 20 Jul 2009 23:21:06 -0400 Original-Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n6L3KcK4003378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 21 Jul 2009 03:20:39 GMT Original-Received: from abhmt009.oracle.com (abhmt009.oracle.com [141.146.116.18]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n6L3L1vW024193 for ; Tue, 21 Jul 2009 03:21:01 GMT Original-Received: from dradamslap1 (/141.144.72.165) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 20 Jul 2009 20:21:00 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoJskSE71+3x2VESxG/FQStUo+qbQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt009.oracle.com [141.146.116.18] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4A65341D.0104:SCFSTAT5015188,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:112886 Archived-At: 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")?