GNU bug report logs - #4157
[macOS/HFS] dired doesn't decode ls output when it uses different encoding for filename vs date

Previous Next

Full log

Message #80 received at 4157 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
Cc: 4157 <at> debbugs.gnu.org
Subject: Re: =?ISO-8859-1?Q?Re:_bug#4157:_23.1.50;_faulty_character_character?= =?ISO-8859-1?Q?isation_for_=E4?=
Date: Thu, 27 Aug 2009 15:52:25 +0900

In article <BB0E3F43-9DA7-42FB-B4F4-63AABC2719DF <at> Freenet.DE>, Peter Dyballa <Peter_Dyballa <at> Freenet.DE> writes:

> > Please try to load ucs-normalize and set
> > file-name-coding-system to utf-8-hfs.  You should see file
> > names correctly by precomposed characters as "ä".

> When I copy a line from a dired buffer with a composed character  
> taken from another font into *scratch* buffer and then apply on the  
> marked file name ucs-normalize-HFS-NFC-region, then the foreign glyph  
> is changed to one from the default font. Automatically this does not  
> happen in dired buffer, although global-auto-composition-mode and  
> auto-composition-mode are both t.

Strange.  On GNU/Linux, I set file-name-coding-system to
utf-8-hfs, create a new file "ä" by:
  ESC : (write-region "test" nil "ä") RET
I confirmed that the file name is surely the two char
sequence of "a" and "̈" by another emacs.

Then M-x dired shows that file name by precomposed character
"ä" (LATIN SMALL LETTER A WITH DIAERESIS).

That means utf-8-hfs does convert the sequence "a" and "̈"
to/from "ä".  I have no idea why it doesn't work in your
environment.

> And ucs-normalize is auto-loaded!

When is it loaded?

---
Kenichi Handa
handa <at> m17n.org

Previous Next

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