From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#11718: 24.1.50; `all-completions' returns results with wrong case Date: Sun, 24 Jun 2012 00:38:21 -0400 Message-ID: References: <87vciss8q2.fsf@web.de> <616F17401403488B8C5153C00AD86CBF@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1340512761 14302 80.91.229.3 (24 Jun 2012 04:39:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 24 Jun 2012 04:39:21 +0000 (UTC) Cc: michael_heerdegen@web.de, 11718@debbugs.gnu.org To: "Drew Adams" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jun 24 06:39:20 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 1SiebX-0006ja-Tl for geb-bug-gnu-emacs@m.gmane.org; Sun, 24 Jun 2012 06:39:20 +0200 Original-Received: from localhost ([::1]:57524 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SiebX-0006Wp-Nh for geb-bug-gnu-emacs@m.gmane.org; Sun, 24 Jun 2012 00:39:19 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39480) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SiebU-0006Wj-W7 for bug-gnu-emacs@gnu.org; Sun, 24 Jun 2012 00:39:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SiebS-0002gQ-W6 for bug-gnu-emacs@gnu.org; Sun, 24 Jun 2012 00:39:16 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45056) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SiebS-0002gI-S9 for bug-gnu-emacs@gnu.org; Sun, 24 Jun 2012 00:39:14 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Sief7-0000kd-Qy for bug-gnu-emacs@gnu.org; Sun, 24 Jun 2012 00:43:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 24 Jun 2012 04:43: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.13405129342833 (code B ref 11718); Sun, 24 Jun 2012 04:43:01 +0000 Original-Received: (at 11718) by debbugs.gnu.org; 24 Jun 2012 04:42:14 +0000 Original-Received: from localhost ([127.0.0.1]:54602 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SieeL-0000je-HJ for submit@debbugs.gnu.org; Sun, 24 Jun 2012 00:42:13 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:53736) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SieeI-0000jV-QW for 11718@debbugs.gnu.org; Sun, 24 Jun 2012 00:42:11 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu0/O+L+Q/2dsb2JhbABEtBGBCIIVAQEEAVYjBQsLNBIUGA0kE4gJBboJixuFKQOjM4FYgwWBOg X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="192003404" Original-Received: from 206-248-191-144.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([206.248.191.144]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 24 Jun 2012 00:38:22 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 862A9AE1E4; Sun, 24 Jun 2012 00:38:21 -0400 (EDT) In-Reply-To: <616F17401403488B8C5153C00AD86CBF@us.oracle.com> (Drew Adams's message of "Sat, 23 Jun 2012 14:01:56 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) 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:61238 Archived-At: Drew, I have no idea what you're hoping to get. I already agreed before you even sent a single message in this thread. It's not like I'm rejecting a patch or something. Stefan >>>>> "Drew" == Drew Adams writes: >> > 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.