From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: Bugs in newly added completion capabilities. Date: Thu, 30 Jun 2005 16:50:58 +0900 Message-ID: References: <200506280227.j5S2Rln23310@raven.dms.auburn.edu> <200506290350.j5T3o7c25749@raven.dms.auburn.edu> <200506300229.j5U2TrL01627@raven.dms.auburn.edu> Reply-To: Miles Bader NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1120118941 10916 80.91.229.2 (30 Jun 2005 08:09:01 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 30 Jun 2005 08:09:01 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 30 10:08:51 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Dnu5z-0003xU-FB for ged-emacs-devel@m.gmane.org; Thu, 30 Jun 2005 10:08:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DnuEB-0007Wd-St for ged-emacs-devel@m.gmane.org; Thu, 30 Jun 2005 04:16:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Dntzc-0006PJ-Kg for emacs-devel@gnu.org; Thu, 30 Jun 2005 04:01:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DntzR-0006KI-Dh for emacs-devel@gnu.org; Thu, 30 Jun 2005 04:01:51 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DntzP-00069f-OA for emacs-devel@gnu.org; Thu, 30 Jun 2005 04:01:40 -0400 Original-Received: from [210.143.35.52] (helo=tyo202.gate.nec.co.jp) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Dntu6-0004Ly-Fd; Thu, 30 Jun 2005 03:56:10 -0400 Original-Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.160] (may be forged)) by tyo202.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id j5U7p2m07794; Thu, 30 Jun 2005 16:51:02 +0900 (JST) Original-Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id j5U7p2r22885; Thu, 30 Jun 2005 16:51:02 +0900 (JST) Original-Received: from relay31.aps.necel.com ([10.29.19.54]) by mailsv.nec.co.jp (8.11.7/3.7W-MAILSV-NEC) with ESMTP id j5U7p2C17576; Thu, 30 Jun 2005 16:51:02 +0900 (JST) Original-Received: from relay31.aps.necel.com ([10.29.19.16] [10.29.19.16]) by relay31.aps.necel.com with ESMTP; Thu, 30 Jun 2005 16:51:01 +0900 Original-Received: from edtmg05.lsi.nec.co.jp ([10.26.17.202] [10.26.17.202]) by relay31.aps.necel.com with ESMTP; Thu, 30 Jun 2005 16:51:01 +0900 Original-Received: from mcsss2.ucom.lsi.nec.co.jp (localhost [127.0.0.1]) by edtmg05.lsi.nec.co.jp (8.12.10/8.12.10) with ESMTP id j5U7p0Gp006305; Thu, 30 Jun 2005 16:51:00 +0900 (JST) Original-Received: from mctpc71 (mctpc71.ucom.lsi.nec.co.jp [10.30.118.121]) by mcsss2.ucom.lsi.nec.co.jp (8.12.10/8.12.8/EDcg v2.01-mc/1046780839) with ESMTP id j5U7oxKt016426; Thu, 30 Jun 2005 16:50:59 +0900 (JST) Original-Received: by mctpc71 (Postfix, from userid 31295) id EB1BD3AA; Thu, 30 Jun 2005 16:50:58 +0900 (JST) Original-To: Luc Teirlinck System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: <200506300229.j5U2TrL01627@raven.dms.auburn.edu> (Luc Teirlinck's message of "Wed, 29 Jun 2005 21:29:53 -0500 (CDT)") Original-Lines: 19 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:39940 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:39940 Luc Teirlinck writes: > Yes, but let me first make sure I understand. Is the reason that we > do not want _any_ symbol as car of the list that forbidding _any_ > symbol as car of the list actually seems _more natural_ than just > forbidding lambda? It seems that any symbol other than lambda can not > be mistaken for the car of an anonymous lambda expresion and hence > could not lead to ambiguity. One possible reason is that if we allow almost all symbol lists, people will tend to overlook the need for a `lambda' special case, write their code to use straight-forward symbol lists -- and odd bugs will arise when lambda does happen to occur at the beginning of such a list. Always requiring an initial "" forces the problem to be dealt with, so will make such code more robust. -Miles -- 97% of everything is grunge