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 #65 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 19:22:03 +0200

> From: Random832 <random832 <at> fastmail.com>
> Date: Wed, 16 Dec 2015 11:00:57 -0500
> 
> > It's not really clear what is correct behavior in this case.  On other
> > platforms Emacs will return only a3, but HFS+ stores decomposed
> > characters precisely to allow all 3 to match.  So I think we should
> > at least cause Emacs return only a3, and ideally also support the
> > other behavior as an option.
> 
> 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.

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

> I'm not sure there's a way around it if we want to be 100%
> correct and consistent, given the existence of parts of the
> completion system that do work with the strings in Unicode.

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.

Previous Next

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