From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: Fixed bug in completing-read Date: Thu, 25 Dec 2003 12:53:24 -0600 (CST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200312251853.hBPIrOq15822@raven.dms.auburn.edu> References: <200312242003.hBOK3el14828@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1072379070 20476 80.91.224.253 (25 Dec 2003 19:04:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 25 Dec 2003 19:04:30 +0000 (UTC) Cc: schwab@suse.de, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Dec 25 20:04:26 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AZamY-0003J5-00 for ; Thu, 25 Dec 2003 20:04:26 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AZamY-0004h0-00 for ; Thu, 25 Dec 2003 20:04:26 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AZbjm-0007kO-NG for emacs-devel@quimby.gnus.org; Thu, 25 Dec 2003 15:05:38 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AZbjg-0007iD-90 for emacs-devel@gnu.org; Thu, 25 Dec 2003 15:05:32 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AZbj8-0007F5-Gc for emacs-devel@gnu.org; Thu, 25 Dec 2003 15:05:31 -0500 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1AZbib-0005rZ-BL; Thu, 25 Dec 2003 15:04:25 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by mx20.gnu.org with esmtp (Exim 4.24) id 1AZaiz-0003QO-L1; Thu, 25 Dec 2003 14:00:45 -0500 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 hBPJ11Kk001516; Thu, 25 Dec 2003 13:01:01 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.6+Sun/8.11.6) id hBPIrOq15822; Thu, 25 Dec 2003 12:53:24 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Thu, 25 Dec 2003 10:33:18 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:18839 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18839 Richard Stallman wrote: Since this is a rather obscure feature, not used in too many places, we should make the decision based on what is clean, not based on compatibility with this or that. Since these positions go with strings, they should be zero-origin. I have reverted my changes in `Fcompleting_read', as well as the related change in ffap.el. The entire treatment of conses as values for INITIAL is back to where it was before my changes, except that a few more functions can handle such values. I do not know whether your remark above only applies to `completing-read' (in which case it is completely taken care of) or also to `read-from-minibuffer' and friends. In the latter case, I would have only one single objection, but a big one. That is the amount of work involved in adapting existing code. The feature is used more often than you seem to believe. I already had my reservations about changing things the other way around, but this way things are a _lot_ worse. (I took a look at it.) The very existence of INITIAL is unclean (it competes with DEFAULT and provides an inconsistent user interface) and it only exists for historical compatibility. Hence, I propose to just document the inconsistency and say that the entire argument, inconsistencies and all, only exists for historical compatibility anyway. Just one more reason to use DEFAULT instead. A semi-obsolete argument is not worth tons of work. Existing code seems to use the argument based on the inconsistency, so no problem there. New code should not use it, so no problem there either. Sincerely, Luc.