From: Stefan Monnier <monnier@iro.umontreal.ca>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: michael_heerdegen@web.de, 11718@debbugs.gnu.org
Subject: bug#11718: 24.1.50; `all-completions' returns results with wrong case
Date: Sun, 24 Jun 2012 00:38:21 -0400 [thread overview]
Message-ID: <jwvbok9z5r9.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <616F17401403488B8C5153C00AD86CBF@us.oracle.com> (Drew Adams's message of "Sat, 23 Jun 2012 14:01:56 -0700")
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.
next prev parent reply other threads:[~2012-06-24 4:38 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
2012-06-24 4:38 ` Stefan Monnier [this message]
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=jwvbok9z5r9.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=11718@debbugs.gnu.org \
--cc=drew.adams@oracle.com \
--cc=michael_heerdegen@web.de \
/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.