From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#11718: 24.1.50; `all-completions' returns results with wrong case Date: Sat, 23 Jun 2012 14:01:56 -0700 Message-ID: <616F17401403488B8C5153C00AD86CBF@us.oracle.com> References: <87vciss8q2.fsf@web.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1340485405 25391 80.91.229.3 (23 Jun 2012 21:03:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 23 Jun 2012 21:03:25 +0000 (UTC) Cc: michael_heerdegen@web.de, 11718@debbugs.gnu.org To: "'Stefan Monnier'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jun 23 23:03:23 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SiXUI-0001jN-43 for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Jun 2012 23:03:22 +0200 Original-Received: from localhost ([::1]:56642 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SiXUH-0000YL-Tk for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Jun 2012 17:03:21 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:49088) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SiXUF-0000YG-2t for bug-gnu-emacs@gnu.org; Sat, 23 Jun 2012 17:03:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SiXUD-0001Vg-4h for bug-gnu-emacs@gnu.org; Sat, 23 Jun 2012 17:03:18 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44827) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SiXUD-0001VR-0o for bug-gnu-emacs@gnu.org; Sat, 23 Jun 2012 17:03:17 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SiXXp-0006n2-S1 for bug-gnu-emacs@gnu.org; Sat, 23 Jun 2012 17:07:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Jun 2012 21:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11718 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11718-submit@debbugs.gnu.org id=B11718.134048558126054 (code B ref 11718); Sat, 23 Jun 2012 21:07:01 +0000 Original-Received: (at 11718) by debbugs.gnu.org; 23 Jun 2012 21:06:21 +0000 Original-Received: from localhost ([127.0.0.1]:54373 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SiXXA-0006mB-Ou for submit@debbugs.gnu.org; Sat, 23 Jun 2012 17:06:21 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:37819) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SiXX8-0006m0-Gl for 11718@debbugs.gnu.org; Sat, 23 Jun 2012 17:06:19 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5NL2Uvd019489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 23 Jun 2012 21:02:30 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q5NL2TPD011893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Jun 2012 21:02:29 GMT Original-Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5NL2Tso008877; Sat, 23 Jun 2012 16:02:29 -0500 Original-Received: from dradamslap1 (/10.159.222.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 23 Jun 2012 14:02:28 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac1RV6oDwd0DTghCQE2CZf+O+OHT1wAKCwaw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:61230 Archived-At: > > But is it not the case that `completing-read' should return > > an actual completion candidate (or a string copy, but with > > the same case at least)? > > Usually, yes, but when quoting is involved, this is not so clear. > If the user typed C-x C-f $TMP/to TAB she liked "$TMP" so Emacs should > not replace it with > "/var/private-tmp-f71dbe52628a3f83a77ab494817525c6/Total" > but with "$TMP/Total". FWIW, the former is what Emacs did before you (someone) changed it, no? E.g. Emacs 22 (or 21 or 20 or ... 18), emacs -Q: (let ((completion-ignore-case t)) (read-file-name "prompt: " nil "foobar")) prompt: $HOME/dre TAB changes the input to /drews-lisp-20/ Whereas Emacs 24 changes it to $HOME/drews-lisp-20/ with $HOME dimmed. But I agree that the handling of env vars can seem to muddy the waters. In any case, the completion candidates themselves are relative file names, and their case reflects the actual file names. And that is so regardless of the platform and regardless of `completion-ignore-case'. IIUC, the candidates themselves do not include any of the $TMP stuff, whether expanded or not. In the case above there is only one matching candidate, "drews-lisp-20" (which is a subdir of the root directory). If that directory were named "DrewsLisp" instead then it should presumably be expanded by Emacs 22 to /DrewsLisp/ and by Emacs 24 to $HOME/DrewsLisp/. Even on a case-insensitive file system such as MS Windows, the resulting file names should be, and have always been, the actual file names. If the file or dir is named TotoFoo then TotoFoo is what we should show and return to the user, even when s?he types `tot TAB'. The laxity wrt case is for the user, and only for matching. It lets the user type `tot' or `Tot' or `TOT' etc. to match `TotoFoo'. It is not the completion code and its return value that we want to be lax with, but the user. It's about user convenience. The returned file name should still be correct, case included. > IOW some of the result should come from the > user's input and some of it from the completion table. > > It's already difficult for Emacs to figure out that "tal" is what was > added, so currently it doesn't try to see that "/to" was changed into > "/To" and that this change is not a form of quoting and > should hence be reflected in the user's input. I cannot speak to the difficulty of a fix or how it is currently evaluated. But it seems to me that Emacs _should_ not change the case of the candidates themselves (whether file names or anything else). The candidates supplied to `completing-read' or computed by a function should be taken as is and returned as chosen. Perhaps with additional boundary text, but not with any case changes. To me, the mission of `completion-ignore-case' is limited to selection of possible matches - it should do nothing except filter. It should have no effect on the returned choice. IOW, I agree that `completion-ignore-case' should "guarantee nothing" about the case of the result. But the requirement is even stronger than that, IMO: `c-i-c' has _nothing to do_ with the form of the result, including its case. Whether the result is uppercase, lowercase, or mixed case should not be affected by the value of `c-i-c'. It should be decided by the completion function (e.g. `read-file-name-internal') or the set of completions provided (e.g. obarray, alist). Do we disagree about this "should"? I cannot speak to the difficulty of implementation. I am not arguing that it is easy to DTRT. But it is not clear whether you agree about what TRT is. Do you think `c-i-g' should have any bearing at all on the case of the result? If so, then we disagree.