[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22169: 25.0.50; File name compiletion doesn't work with non-ASCII ch
From: |
Random832 |
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 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Eli Zaretskii <eliz@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.
- bug#22169: 25.0.50; File name compiletion doesn't work with non-ASCII characters on OS X, (continued)
- bug#22169: 25.0.50; File name compiletion doesn't work with non-ASCII characters on OS X, Random832, 2015/12/15
- bug#22169: 25.0.50; File name compiletion doesn't work with non-ASCII characters on OS X, Eli Zaretskii, 2015/12/15
- bug#22169: 25.0.50; File name compiletion doesn't work with non-ASCII characters on OS X, Random832, 2015/12/16
- bug#22169: 25.0.50; File name compiletion doesn't work with non-ASCII characters on OS X, Eli Zaretskii, 2015/12/16
- bug#22169: 25.0.50; File name compiletion doesn't work with non-ASCII characters on OS X, Random832, 2015/12/16
- bug#22169: 25.0.50; File name compiletion doesn't work with non-ASCII characters on OS X, Eli Zaretskii, 2015/12/16
- bug#22169: 25.0.50; File name compiletion doesn't work with non-ASCII characters on OS X,
Random832 <=
- bug#22169: 25.0.50; File name compiletion doesn't work with non-ASCII characters on OS X, Eli Zaretskii, 2015/12/16
bug#22169: 25.0.50; File name compiletion doesn't work with non-ASCII characters on OS X, Random832, 2015/12/14
bug#22169: 25.0.50; File name compiletion doesn't work with non-ASCII ch, Anders Lindgren, 2015/12/14