GNU bug report logs - #22169
25.0.50; File name compiletion doesn't work with non-ASCII characters on OS X

Previous Next

Package: emacs;

Reported by: Anders Lindgren <andlind <at> gmail.com>

Date: Mon, 14 Dec 2015 19:09:01 UTC

Severity: normal

Found in version 25.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Random832 <random832 <at> fastmail.com>
To: 22169 <at> debbugs.gnu.org
Subject: bug#22169: 25.0.50; File name compiletion doesn't work with non-ASCII characters on OS X
Date: Wed, 16 Dec 2015 13:19:20 -0500
Eli Zaretskii <eliz <at> gnu.org> writes:
>> I'm not aware of any published rationale for the decision to
>> store decomposed characters.
>
> It cannot be anything other than the desire to support lax matches.

Maybe. I half suspect it was just to make their case mapping
table (which doesn't include entries for the precomposed
characters) smaller.

>> I think maybe lax matching as an option would be better than
>> blindly doing comparisons based on the decomposed form.
>
> It could be, if we had the lax matching implemented in C.  But we
> currently only emulate that with complex regexps, and I think it's not
> a good idea to call that from dired.c.

Whether that ever gets implemented or not, what I meant to
suggest is that a half-baked lax matching that only works for a
small subset of situations and only on one platform is not a
feature worth having at all. And if people really do want it
they can have it today by setting the encoding to utf-8 and
dealing with the backspacing weirdness.

AFAICT the rationale for renormalizing filenames to NFC was that
combining characters couldn't be *displayed* on Carbon Emacs,
rather than there being anything especially undesirable about
the backspacing behavior.

> I could come up with a patch if someone's interested to try it.  I
> just want to hear first about the details of what happens in
> file_name_completion that causes file-name-all-completions return nil
> in the OP's case.  There's got to be something that I'm missing here.

Like I said, ns-win's utf-8-nfd doesn't normalize on encode.
I've since confirmed this with encode-coding-string.  I haven't
been able to confirm that ucs-normalize's utf-8-hfs exhibits the
problem behavior.





This bug report was last modified 9 years and 154 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.