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: Wed, 24 Dec 2003 14:03:40 -0600 (CST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200312242003.hBOK3el14828@raven.dms.auburn.edu> References: NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1072296803 18704 80.91.224.253 (24 Dec 2003 20:13:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 24 Dec 2003 20:13:23 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Dec 24 21:13:19 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 1AZFNf-0005v9-00 for ; Wed, 24 Dec 2003 21:13:19 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AZFNf-0006xE-00 for ; Wed, 24 Dec 2003 21:13:19 +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 1AZGJi-0002pN-OG for emacs-devel@quimby.gnus.org; Wed, 24 Dec 2003 16:13:18 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AZGJQ-0002oB-22 for emacs-devel@gnu.org; Wed, 24 Dec 2003 16:13:00 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AZGIq-0002aQ-TA for emacs-devel@gnu.org; Wed, 24 Dec 2003 16:12:56 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AZGIq-0002RH-Ju for emacs-devel@gnu.org; Wed, 24 Dec 2003 16:12:24 -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 hBOKBDKk000531; Wed, 24 Dec 2003 14:11:13 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.6+Sun/8.11.6) id hBOK3el14828; Wed, 24 Dec 2003 14:03:40 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: schwab@suse.de In-reply-to: (message from Andreas Schwab on Wed, 24 Dec 2003 18:29:35 +0100) 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:18819 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18819 Andreas Schwab wrote: "POSITION characters into string" == "at position POSITION in the minibuffer" - 1. String positions are zero-origin, buffer positions are one-origin. To me, the English phrase "POSITION characters into string" is equivalent with the technical Lisp phrase "at (zero-indexed) position POSITION - 1 in string". I could be wrong and, clearly, you understand it differently. The one thing this means for certain is that things should be reformulated more unambiguously, in all involved places, which I will do. IMHO the behaviour of read-from-minibuffer is actually what should be changed, because the Elisp manual describes it like this: Alternatively, INITIAL-CONTENTS can be a cons cell of the form `(STRING . POSITION)'. This means to insert STRING in the minibuffer but put point POSITION characters from the beginning, rather than at the end. Again, to me, the English phrase "POSITION characters from the beginning" agrees with the behavior of read-from-minibuffer and contradicts the old behavior of completing-read. Again, I could be wrong. Same remark as above. Anyway, terminology aside, we have three choices: 1. Adapt `completing-read' to `read-from-minibuffer'. This is done in current CVS. 2. Adapt `read-from-minibuffer' to `completing-read', as you propose. 3. Keep the pre-yesterday behavior and clearly document the difference in behavior. When I first brought this up, I offered to implement either (1) or (3). Richard decided on (1). I could easily implement (2) too, if it would be decided that this would be better. In terms of "writing the code", it just means adding or erasing a + 1 or -1, completely trivial, and we do not need to undo the moving of the involved code into read_minibuf, which was necessary, because certain functions claimed they could handle conses for INITIAL, whereas they could not (they can now). Note that (2) would break existing code, just like (1) does, and it would be equally difficult to find all that code. (3) does not have that problem, but the inconsistency is ugly and confusing. If we decide to stay with (1), I would adapt `read-file-name'. Maybe it might be good to move the duplicate (but currently, in as far as I know, consistent) treatment of the HISTORY argument from `read-from-minibuffer' and `completing-read' into `read_minibuf', as was done for INITIAl, just to prevent future inconsistencies from developing. I could easily do so, if desired. Sincerely, Luc.