From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: Bugs in newly added completion capabilities. Date: Thu, 30 Jun 2005 13:28:21 -0500 (CDT) Message-ID: <200506301828.j5UISL305879@raven.dms.auburn.edu> References: <200506280227.j5S2Rln23310@raven.dms.auburn.edu> <200506290350.j5T3o7c25749@raven.dms.auburn.edu> <200506300229.j5U2TrL01627@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1120156348 29351 80.91.229.2 (30 Jun 2005 18:32:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 30 Jun 2005 18:32:28 +0000 (UTC) Cc: emacs-devel@gnu.org, rms@gnu.org, miles@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 30 20:32:25 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Do3pW-0002op-E2 for ged-emacs-devel@m.gmane.org; Thu, 30 Jun 2005 20:32:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Do3s4-00037o-Tl for ged-emacs-devel@m.gmane.org; Thu, 30 Jun 2005 14:34:44 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Do3qw-0002yy-6N for emacs-devel@gnu.org; Thu, 30 Jun 2005 14:33:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Do3qt-0002x1-J7 for emacs-devel@gnu.org; Thu, 30 Jun 2005 14:33:31 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Do3qt-0002wZ-G1 for emacs-devel@gnu.org; Thu, 30 Jun 2005 14:33:31 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Do3sd-00080G-Gm; Thu, 30 Jun 2005 14:35:19 -0400 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id j5UIUCCK000489; Thu, 30 Jun 2005 13:30:13 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j5UISL305879; Thu, 30 Jun 2005 13:28:21 -0500 (CDT) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: monnier@iro.umontreal.ca In-reply-to: (message from Stefan Monnier on Thu, 30 Jun 2005 13:42:15 -0400) 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:39966 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:39966 Stefan Monnier wrote: Honestly, what's so great about being able to use lists of symbols rather than lists of strings? In Emacs-21, we don't even allow lists of strings, but only lists of pairs whose car is a string, and people haven't complained about it. I am not arguing for allowing lists of symbols rather than lists of strings, but mixed lists of strings and symbols _are_ currently allowed and try-completion and all-completions now nearly everywhere treat symbols as being completely equivalent to (symbol-name 'symbol) 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. 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. Secondly, try-completion and all-completions are mainly used by minibuffer completion functions that can also pass the same argument to test-completion. If test-completion treats this argument differently from the other two (as it currently does), there is the obvious potential for trouble. So either one just reverts the 2005-02-22 change, or one needs to take care of the inconsistency problems I pointed out. 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. Sincerely, Luc.