From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>
Cc: michael_heerdegen@web.de, 11718@debbugs.gnu.org
Subject: bug#11718: 24.1.50; `all-completions' returns results with wrong case
Date: Sat, 23 Jun 2012 14:01:56 -0700 [thread overview]
Message-ID: <616F17401403488B8C5153C00AD86CBF@us.oracle.com> (raw)
In-Reply-To: <jwv7guy82be.fsf-monnier+emacs@gnu.org>
> > 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.
next prev parent reply other threads:[~2012-06-23 21:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-15 18:58 bug#11718: 24.1.50; `all-completions' returns results with wrong case Michael Heerdegen
2012-06-23 4:38 ` Stefan Monnier
2012-06-23 14:18 ` Drew Adams
2012-06-23 15:48 ` Stefan Monnier
2012-06-23 21:01 ` Drew Adams [this message]
2012-06-24 4:38 ` Stefan Monnier
2012-06-24 14:33 ` Drew Adams
2012-06-24 16:38 ` Stefan Monnier
2012-06-24 20:20 ` Drew Adams
2012-06-25 1:38 ` Stefan Monnier
2012-06-26 2:17 ` Michael Heerdegen
2012-06-26 13:06 ` Stefan Monnier
2012-06-23 19:51 ` Michael Heerdegen
2016-07-08 23:17 ` npostavs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=616F17401403488B8C5153C00AD86CBF@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=11718@debbugs.gnu.org \
--cc=michael_heerdegen@web.de \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.