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: RE: Should nil COLLECTION element mean a "nil" candidate for completing-read? Alist doc. Date: Tue, 21 Jul 2009 17:07:51 -0700 Message-ID: <6BEC3A55E55C44CDB98BC4F58101851C@us.oracle.com> References: <5721FBADB175440B9BA3383934E0AC30@us.oracle.com><6878F4119A994982A06767B5C83E92DB@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 1248221313 29236 80.91.229.12 (22 Jul 2009 00:08:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Jul 2009 00:08:33 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 22 02:08:26 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 1MTPNi-0003Ua-D7 for ged-emacs-devel@m.gmane.org; Wed, 22 Jul 2009 02:08:26 +0200 Original-Received: from localhost ([127.0.0.1]:41534 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTPNh-0004Ws-Ph for ged-emacs-devel@m.gmane.org; Tue, 21 Jul 2009 20:08:25 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MTPNK-0004Lg-1z for emacs-devel@gnu.org; Tue, 21 Jul 2009 20:08:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MTPNF-0004Jn-EY for emacs-devel@gnu.org; Tue, 21 Jul 2009 20:08:01 -0400 Original-Received: from [199.232.76.173] (port=50347 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTPNF-0004Jk-BJ for emacs-devel@gnu.org; Tue, 21 Jul 2009 20:07:57 -0400 Original-Received: from acsinet11.oracle.com ([141.146.126.233]:51444) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MTPNE-0002tn-PK for emacs-devel@gnu.org; Tue, 21 Jul 2009 20:07:57 -0400 Original-Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n6M083Bk030308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Jul 2009 00:08:05 GMT Original-Received: from abhmt002.oracle.com (abhmt002.oracle.com [141.146.116.11]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n6M07n5s023092; Wed, 22 Jul 2009 00:07:50 GMT Original-Received: from dradamslap1 (/141.144.72.165) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 Jul 2009 17:07:49 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcoKG8Dj0FB2RptiQZS1oJFggquxiQAP5iLw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt002.oracle.com [141.146.116.11] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010209.4A665856.0061: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:112965 Archived-At: > > What does that mean? Are you simply saying "don't do that" - users > > must ensure that there are no nil elements in the COLLECTION arg? > > Yes. Too bad. > > And what about the rest of my post, regarding the doc > > contradictions and > > confusion wrt alist elements? > > Same idea: > > > 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 > your own. 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". 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 "nil". 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 elements. 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.