bug#11718: 24.1.50; `all-completions' returns results with wrong case

[Stefan Monnier]

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@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.