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: Eli Zaretskii <eliz <at> gnu.org>
To: Random832 <random832 <at> fastmail.com>
Cc: 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 20:51:47 +0200
> From: Random832 <random832 <at> fastmail.com>
> 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.

Only if they force decomposition in contexts that have nothing to do
with file names.  Otherwise, they will have to have those large case
tables anyway, for other kinds of text, right?

> 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.

It is generally easier and more convenient to have precomposed
characters, yes.  It's not an accident that no other filesystem does
this kind of decomposition; Windows filesystems actually compose the
characters, AFAIK.

> > 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.

Let's hope you are right.




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.