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: Tue, 23 Dec 2003 21:18:43 -0600 (CST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200312240318.hBO3IhB14118@raven.dms.auburn.edu> References: <200312180325.hBI3PSm02368@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1072236397 22407 80.91.224.253 (24 Dec 2003 03:26:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 24 Dec 2003 03:26:37 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Dec 24 04:26:34 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 1AYzfO-0001oR-00 for ; Wed, 24 Dec 2003 04:26:34 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AYzfN-0004Ce-00 for ; Wed, 24 Dec 2003 04:26:33 +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 1AZ0co-00028x-44 for emacs-devel@quimby.gnus.org; Tue, 23 Dec 2003 23:27:58 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AZ0cj-00028n-MF for emacs-devel@gnu.org; Tue, 23 Dec 2003 23:27:53 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AZ0cD-00021Q-Iz for emacs-devel@gnu.org; Tue, 23 Dec 2003 23:27:52 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AZ0cD-00021M-8X for emacs-devel@gnu.org; Tue, 23 Dec 2003 23:27:21 -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 hBO3QFKk029368; Tue, 23 Dec 2003 21:26:15 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.6+Sun/8.11.6) id hBO3IhB14118; Tue, 23 Dec 2003 21:18:43 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: teirllm@dms.auburn.edu In-reply-to: <200312180325.hBI3PSm02368@raven.dms.auburn.edu> (message from Luc Teirlinck on Wed, 17 Dec 2003 21:25:28 -0600 (CST)) 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:18806 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18806 I have fixed (in CVS) the bug I in `completing-read' which I reported in my previous message. Some packages may _rely_ on the bug. This concerns the initial position of point in an inserted default string after entering the minibuffer. In the (rare) case where the INITIAL argument to `completing-read' is a cons of a string and an integer (as opposed to just a string),`completing-read' used to put point one positiom more to the right than `read-from-minibuffer', contradicting its own documentation string. This is now fixed. There is no change in the (usual) case where INITIAL is just a string: point appears at the end of the inserted string. In nearly all cases where initial is a cons, the purpose was to make point appear at the _beginning_ of the inserted string. To get around the bug, many packages specified a position of 0 instead of 1. This is *no problem*. _Any_ integer 1 _or_ less puts point at the beginning of the string. The *only* time there is a problem is when one tries to put point somewhere in the _middle_ of the inserted string. In that case, point will now appear one position more to the _left_ than intended. This can trivially be fixed by adding 1 to the formula computing the position. I fixed the one single example I knew of. However, the number of calls to `completing-read' is so huge and many calls are so complex, that it is impossible to be certain that there are no other cases. So, if after entry to the minibuffer, on a function that provides completion, point appears one position too far to the left in the pre-inserted string, you know what the problem is and it is trivial to fix. Sincerely, Luc.