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: Bug in completing-read Date: Wed, 17 Dec 2003 21:25:28 -0600 (CST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200312180325.hBI3PSm02368@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1071718507 16031 80.91.224.253 (18 Dec 2003 03:35:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 18 Dec 2003 03:35:07 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Dec 18 04:35:03 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 1AWowJ-0005ud-00 for ; Thu, 18 Dec 2003 04:35:03 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AWowJ-0007w1-00 for ; Thu, 18 Dec 2003 04:35:03 +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 1AWps5-0004fQ-OX for emacs-devel@quimby.gnus.org; Wed, 17 Dec 2003 23:34:45 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AWprj-0004ch-Dk for emacs-devel@gnu.org; Wed, 17 Dec 2003 23:34:23 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AWprD-0004Ft-DN for emacs-devel@gnu.org; Wed, 17 Dec 2003 23:34:22 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AWprC-0004Fq-NK for emacs-devel@gnu.org; Wed, 17 Dec 2003 23:33:50 -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 hBI3WdKk024144 for ; Wed, 17 Dec 2003 21:32:40 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.6+Sun/8.11.6) id hBI3PSm02368; Wed, 17 Dec 2003 21:25:28 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: emacs-devel@gnu.org 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:18734 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18734 If one evaluates: (read-from-minibuffer "Input: " '("123456789" . 3)) point appears on the "3" in the minibuffer. But if one evaluates: (completing-read "Input: " '("123456789") nil nil '("123456789" . 3)) point appears on the "4" in the minibuffer. This is inconsistent and it also contradicts the documentation string of `completing-read'. In other words, the behavior of `completing-read' is an obvious bug. It is trivial to fix, in fact I "inadvertently" fixed it in my own private Emacs. In another thread ("read-from-minibuffer and friends"), I proposed a patch that will move the handling of string-integer conses of the type used above from Fread_from_minibuffer into read_minibuf. (Not yet installed because of the Savannah situation.) After proposing that patch I made some small further changes. (I got rid of variables that were no longer used, but which I inadvertently forgot to remove.) But then I noticed nearly identical code in Fcompleting_read. I removed this now redundant code. But while diffing I noticed that a "-1" was missing in a formula in the removed code. At first sight, wonderful. Code gone, bug gone, end of story. Now the problem. People using such arguments to `completing-read' apparently found it easier to just get around the bug by putting the "-1" in their own code, rather than reporting it or fixing it in minibuf.c. So now we are left with the following choice: 1. Document this inconsistency in the documentation string of `completing-read', as well as in the Elisp manual, and say that it exists for historical compatibility. (I could do that, if that is what we decide to do.) 2. Fix the bug and also fix existing code that relies on the bug. (I could trivially fix the bug, if that is what we decide to do. As mentioned above, I have already fixed it in my personal Emacs. Finding _all_ code relying on the bug seems very non-trivial, however, because `completing-read' is used so often.) Example: M-x load-library RET ffap M-: (ffap-read-file-or-url "Input: " "myfile") RET Result: Input: ~/emacscvsdir/emacs/lisp/myfile with point on the `m' of myfile, as probably intended. Fixing the bug in `completing-read' would put it on the last `/'. So do we fix this bug or make the inconsistency an "official, but deprecated, feature" by documenting it? Sincerely, Luc.