From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Bugs in newly added completion capabilities. Date: Fri, 01 Jul 2005 10:14:08 +0200 Message-ID: References: <200506280227.j5S2Rln23310@raven.dms.auburn.edu> <200506290350.j5T3o7c25749@raven.dms.auburn.edu> <200506300229.j5U2TrL01627@raven.dms.auburn.edu> <200506301828.j5UISL305879@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1120208657 18022 80.91.229.2 (1 Jul 2005 09:04:17 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 1 Jul 2005 09:04:17 +0000 (UTC) Cc: miles@gnu.org, monnier@iro.umontreal.ca, rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 01 11:04:13 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DoHRT-0005XB-J3 for ged-emacs-devel@m.gmane.org; Fri, 01 Jul 2005 11:04:11 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DoHZt-0007HI-LL for ged-emacs-devel@m.gmane.org; Fri, 01 Jul 2005 05:12:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DoGw2-0003lw-5M for emacs-devel@gnu.org; Fri, 01 Jul 2005 04:31:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DoGsj-0003bU-D2 for emacs-devel@gnu.org; Fri, 01 Jul 2005 04:28:42 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DoGip-0003J5-SZ for emacs-devel@gnu.org; Fri, 01 Jul 2005 04:18:07 -0400 Original-Received: from [195.41.46.236] (helo=pfepb.post.tele.dk) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DoGkT-0002Wq-4P; Fri, 01 Jul 2005 04:19:45 -0400 Original-Received: from kfs-l.imdomain.dk.cua.dk (unknown [80.165.4.124]) by pfepb.post.tele.dk (Postfix) with SMTP id 67A265EE07D; Fri, 1 Jul 2005 10:14:26 +0200 (CEST) Original-To: Luc Teirlinck In-Reply-To: <200506301828.j5UISL305879@raven.dms.auburn.edu> (Luc Teirlinck's message of "Thu, 30 Jun 2005 13:28:21 -0500 (CDT)") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:40014 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:40014 Luc Teirlinck writes: > since the following change made relatively recently (I thought we were > in a feature freeze, but anyway): > > 2005-02-22 Kim F. Storm > > * minibuf.c (Ftry_completion, Fall_completions): Allow > both string and symbol keys in alists and hash tables. > > Again I am not arguing for or against the desirability of this change, > I am trying to deal with its consequences. I changed them to support the following change: 2005-02-22 Kim F. Storm * progmodes/hideif.el (hide-ifdef-use-define-alist): Use completing-read. Suggested by Juan-Leon Lahoz Garcia. > There are two problems: the _nearly_ everywhere is very inconsistent > and the exceptions at first seem totally arbitrary, so it should be > clearly documented what the exceptions are and what the motivation for > the exceptions is. I don't think there were any explicit motivation (rather oversight on my part) -- better fix the code to DTRT. Please do. > I don't like the idea of adding "" at the beginning of a completion table. > Here I have a good reason, which is that it changes the behavior: > > (try-completion "" '("aaa" "aab" "aac")) => "aa" > (try-completion "" '("" "aaa" "aab" "aac")) => "" > > Of course, the person consing "" to the front of the completion table > will have to write his code to expect the second answer. Perhaps a check to see if first elt is lambda and second elt is a list would be a reasonable way to recognize a lambda form. -- Kim F. Storm http://www.cua.dk