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

Previous Next

Full log

Message #53 received at 22169 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Random832 <random832 <at> fastmail.com>
Cc: 22169 <at> debbugs.gnu.org
Subject: Re: bug#22169: 25.0.50;
 File name compiletion doesn't work with non-ASCII characters on OS X
Date: Wed, 16 Dec 2015 05:32:56 +0200

> From: Random832 <random832 <at> fastmail.com>
> Date: Tue, 15 Dec 2015 16:53:37 -0500
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> >   . encode the file argument
> >   . encode the directory argument and pass it to opendir
> >   . loop calling readdir, and for each file name it returns:
> >     . if the file name begins with the same characters as the encoded
> >       file argument, then:
> >       . decode the file name
> >       . cons the decoded name onto the list to be returned
> 
> My guess from the symptoms is that utf-8-nfd doesn't actually
> bother to make any attempt to convert to decomposed form when
> encoding, since in *most* cases e.g. for opening a file, the
> underlying filesystem will take care of this automatically.
> 
> This is backed up by the fact that, looking at the code, it
> apparently has a post-read-conversion but no matching
> pre-write-conversion.

I certainly see a pre-write-conversion function in ucs-normalize.el:
ucs-normalize-hfs-nfd-pre-write-conversion which calls
ucs-normalize-HFS-NFD-region.  So I'm not sure I understand what you
are saying.

Previous Next

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