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" candidateforcompleting-read? Alist doc. Date: Tue, 21 Jul 2009 17:07:53 -0700 Message-ID: <491580B15C204D059258DF3BD7740465@us.oracle.com> References: <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 1248221358 29340 80.91.229.12 (22 Jul 2009 00:09:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Jul 2009 00:09:18 +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:09:11 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 1MTPOR-0003gT-KH for ged-emacs-devel@m.gmane.org; Wed, 22 Jul 2009 02:09:11 +0200 Original-Received: from localhost ([127.0.0.1]:42037 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTPOQ-0004rK-Sd for ged-emacs-devel@m.gmane.org; Tue, 21 Jul 2009 20:09:10 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MTPNK-0004MF-Ry 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 1MTPNG-0004K1-5h for emacs-devel@gnu.org; Tue, 21 Jul 2009 20:08:02 -0400 Original-Received: from [199.232.76.173] (port=50348 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTPNG-0004Jw-3A for emacs-devel@gnu.org; Tue, 21 Jul 2009 20:07:58 -0400 Original-Received: from acsinet11.oracle.com ([141.146.126.233]:51474) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MTPNF-0002u5-G9 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 n6M085gB030357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Jul 2009 00:08:07 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 n6M07qdb023130; Wed, 22 Jul 2009 00:07:52 GMT Original-Received: from dradamslap1 (/141.144.72.165) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 Jul 2009 17:07:51 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcoKHUflvW3MPhPpQ4qYNbVI8PA5bQAPybqA 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.0A010207.4A665858.004A: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:112966 Archived-At: > > I forgot to point out that treating nil this way can lead to extra > > (ugly) code, just to remove or prevent production of such > > nil entries, > > so they are not available to the user. > > A completion table can be a list of strings, a list of conses > where the car is a string, an obarry, a hashtable, or a function. > Your "table" is none of those, so it's invalid. Adding > (delq nil ...) before passing that table to the completion > functions doesn't seem like a big issue. First, it's not "my table". ;-) More importantly: 1. Adding `delq' means a separate pass over the list (which can be big). Preventing inclusion of nil, as an alternative, requires uglier, less clear code (e.g. code that pushes an element to the list when it is non-nil). 2. Saying that users can do that as a workaround ("y'a qu'a") is a cop-out. This is not documented - it's simply a gotcha. Users won't even know they must do that, except through accidental discovery by trial and error (which is how I discovered it). It is all too easy to create a list that might have some extraneous nil elements - and not even be aware of them. Hence, this is also error-prone. > > IOW, I suspect that the number of times where this > > "feature" might be useful (for what?) is less than > > the number of times where it is a nuisance. > > It's not a feature. Right; it's a bug - a regression wrt Emacs 21, in fact (you admit it wasn't added intentionally, as a feature, and it is a user-visible change in behavior). It is undocumented behavior that contradicts the documented behavior. The general doc for alists says that nil entries will be ignored. Exceptions to that should be documented. You want to neither fix the code (so it will ignore nil entries) nor document this change in behavior (since Emacs 21). That's not right. I pose the questions: Should nil be ignored here? Should nil be treated like the string "nil" here? Those are "should" questions. It's not sufficient to avoid a response and take the view that the behavior is what it is and should not be documented. I'm asking what the behavior _should_ be. And the doc should describe what the function does - _especially_ considering any special treatment, which is not obvious.