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

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

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