GNU bug report logs - #11718
24.1.50; `all-completions' returns results with wrong case

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: michael_heerdegen <at> web.de, 11718 <at> debbugs.gnu.org
Subject: bug#11718: 24.1.50; `all-completions' returns results with wrong case
Date: Sun, 24 Jun 2012 00:38:21 -0400

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 <drew.adams <at> oracle.com> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.