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: Anders Lindgren <andlind <at> gmail.com>
Cc: schwab <at> suse.de, 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: Tue, 15 Dec 2015 18:11:45 +0200
> Date: Tue, 15 Dec 2015 11:21:17 +0100
> From: Anders Lindgren <andlind <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 22169 <at> debbugs.gnu.org
> 
>     > I tried setting it to nil. This made completion work. However, the
>     letters
>     > are presented in decomposed form, so that pressing backspace first
>     converts
>     > "å" to "a", a second backspace deletes the "a" -- this is not how we
>     would
>     > like to present file names to users.
>     
>     That's how composed characters work in Emacs.
> 
> The OS X file system *stores* filenames in a decomposed manner, that is true.
> However, they should be presented to the user as normal (composed) characters.
> If `file-name-coding-system' has the original value, they are. However, the
> problem is that the completion mechanism fails to handle this case, which is a
> bug and it should be fixed.

Andreas just pointed out that when character composition happens at
display time, the behavior you observe is normal, that's all.

The issue of why completion doesn't work still exists.




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.