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

["Drew Adams" <drew.adams@oracle.com>]

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