bug#4157: 23.1.50; faulty character characterisation for ä

[川幡太一]

Hi,

I'm on the side of keeping the name of the coding-system to be 'utf-8-hfs',
as this coding system is defined by the specification of HFS+
(http://developer.apple.com/technotes/tn/tn1150.html), rather than
MacOS itself.   This implies that if other OS mounts HFS, they should
still apply "modified-NFD" for the file names.

Besides, the other components of MacOS handles UTF-8 as NFC, as seen
by the spotlight, etc.

It is very unfortunate (and possibly flaw) of Carbon API that they do not
care the file system they are accessing.  One must care by himself when
copying files among different file systems.  (For example, when I back-up
files among file systems with "rsync", I usually put some options such
as "--iconv=UTF8-MAC,UTF-8")... sigh....

Cheers,

2009/9/4 Kenichi Handa <handa@m17n.org>:
> In article <0B33C588-C7AD-41D9-8CAC-51AEBD40B264@Freenet.DE>, Peter Dyballa 
> <Peter_Dyballa@Freenet.DE> writes:
>
>> My test files were originally on an HFS+ and on an UFS (UNIX File
>> System) volume (partition, slice, ...). This evening I copied them to
>> an MS-DOS FAT16 file system. When I invoke GNU Emacs with -Q I see in
>> all three file systems the decomposed characters in the file names.
>> With ucs-normalize loaded and file-name-coding-system set to utf-8-
>> hfs the look in all three file systems OK. This makes the chosen name
>> utf-8-hfs not the best. Maybe utf-8-osx is more appropriate.
>
> In article <jwv8wgz4jkj.fsf-monnier+emacsbugreports@gnu.org>, Stefan Monnier 
> <monnier@iro.umontreal.ca> writes:
>
>> Good point.  Or maybe utf-8-darwin.
>
> Kawabata-san, what do you think?
>
> ---
> Kenichi Handa
> handa@m17n.org
>



-- 
---------------------------------------------------------------------
　川幡 太一 (KAWABATA, Taichi)　　　E-mail: kawabata@clock.ocn.ne.jp
　　　　　　　　　　　　　　　　　　kawabata.taichi@gmail.com