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 07:18:00 -0700 Message-ID: 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 1340461167 28145 80.91.229.3 (23 Jun 2012 14:19:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 23 Jun 2012 14:19:27 +0000 (UTC) Cc: 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 16:19:26 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 1SiRBL-00035q-QV for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Jun 2012 16:19:24 +0200 Original-Received: from localhost ([::1]:36530 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SiRBL-0002lO-LH for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Jun 2012 10:19:23 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60040) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SiRBI-0002lH-Bd for bug-gnu-emacs@gnu.org; Sat, 23 Jun 2012 10:19:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SiRBG-0005Bn-36 for bug-gnu-emacs@gnu.org; Sat, 23 Jun 2012 10:19:19 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44542) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SiRBF-0005Bj-Vo for bug-gnu-emacs@gnu.org; Sat, 23 Jun 2012 10:19:18 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SiREr-0004h3-LR for bug-gnu-emacs@gnu.org; Sat, 23 Jun 2012 10:23: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 14:23: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.134046134117989 (code B ref 11718); Sat, 23 Jun 2012 14:23:01 +0000 Original-Received: (at 11718) by debbugs.gnu.org; 23 Jun 2012 14:22:21 +0000 Original-Received: from localhost ([127.0.0.1]:54087 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SiRED-0004g5-Ef for submit@debbugs.gnu.org; Sat, 23 Jun 2012 10:22:21 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:19594) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SiREB-0004fy-P9 for 11718@debbugs.gnu.org; Sat, 23 Jun 2012 10:22:20 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5NEIXRm012619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 23 Jun 2012 14:18:34 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q5NEIWrc027664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Jun 2012 14:18:33 GMT Original-Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5NEIWJW021909; Sat, 23 Jun 2012 09:18:32 -0500 Original-Received: from dradamslap1 (/10.159.222.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 23 Jun 2012 07:18:32 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac1Q+gkzd/2j41OsT4e30u42B6GeRwATUqZw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] 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:61218 Archived-At: > > I have a directory "~/Trash". If I eval > > (let ((completion-ignore-case t)) > > (all-completions "~/tra" 'read-file-name-internal > > 'file-exists-p nil)) > > in emacs -Q, I get > > (#("trash/" 0 3 (face completions-common-part))) > > Note the wrong lower case of the result. > > While not strictly wrong, See below. > it is indeed an undesirable result. > I'll try and see how to fix it. > > > Not sure if this is really a bug, but, at least, this change in > > behavior is documented nowhere, and it causes a completion bug in > > Icicles. > > Sounds like it hits a real Icicles bug: there are rather few > guarantees about the actual case of the returned string when > completion-ignore-case is set. So while we do want to fix the > problem, code should not assume anything about the particular > case of the return string (which is only considered to be a > "cosmetic" issue). I don't know what the Icicles connection is. 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)? If a candidate is "Trash" and that candidate is chosen then it should not return "trash" or "TRASH" or "trAsh", no? Likewise, for `read-file-name': If the actual file-name candidate is "Trash" then it should not return "trash", no? I would think this would be true regardless of the value of `completion-ignore-case'. That variable should control only completion _matching_, acting as a filter. It should not affect/alter the completion candidate that is returned. To perform case-insensitive matching it would be permissible as a matching implementation to uppercase or lowercase everything and then compare. But such an implementation should not provide an excuse to _return_ such a massaged candidate. The original candidate (or a string copy) should be returned. `completion-ignore-case' should not affect the result in any way. That's the only proper interpretation of "no guarantees wrt the result": it should have no effect on the result. It should affect only whether one of the candidates proposed matches your input. Returning one of the actual completion candidates (or a `string=' copy), and not returning its uncle or "halloween" or its mirror image or ... is not a "cosmetic" issue. So it seems to me, and I see nothing in either the doc or in past Emacs behavior to contradict that. Ignoring case during completion, just like a PREDICATE arg, has only to do with matching. Or so it should.