[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11718: 24.1.50; `all-completions' returns results with wrong case
From: |
Drew Adams |
Subject: |
bug#11718: 24.1.50; `all-completions' returns results with wrong case |
Date: |
Sat, 23 Jun 2012 07:18:00 -0700 |
> > 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.
- bug#11718: 24.1.50; `all-completions' returns results with wrong case, Michael Heerdegen, 2012/06/15
- bug#11718: 24.1.50; `all-completions' returns results with wrong case, Stefan Monnier, 2012/06/23
- bug#11718: 24.1.50; `all-completions' returns results with wrong case,
Drew Adams <=
- bug#11718: 24.1.50; `all-completions' returns results with wrong case, Stefan Monnier, 2012/06/23
- bug#11718: 24.1.50; `all-completions' returns results with wrong case, Drew Adams, 2012/06/23
- bug#11718: 24.1.50; `all-completions' returns results with wrong case, Stefan Monnier, 2012/06/24
- bug#11718: 24.1.50; `all-completions' returns results with wrong case, Drew Adams, 2012/06/24
- bug#11718: 24.1.50; `all-completions' returns results with wrong case, Stefan Monnier, 2012/06/24
- bug#11718: 24.1.50; `all-completions' returns results with wrong case, Drew Adams, 2012/06/24
- bug#11718: 24.1.50; `all-completions' returns results with wrong case, Stefan Monnier, 2012/06/24
- bug#11718: 24.1.50; `all-completions' returns results with wrong case, Michael Heerdegen, 2012/06/25
- bug#11718: 24.1.50; `all-completions' returns results with wrong case, Stefan Monnier, 2012/06/26
- bug#11718: 24.1.50; `all-completions' returns results with wrong case, Michael Heerdegen, 2012/06/23