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 #60 received at 4157 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 4157 <at> debbugs.gnu.org
Subject: Re: bug#4157: 23.1.50; faulty character characterisation for ä
Date: Mon, 24 Aug 2009 17:21:09 +0200

Am 24.08.2009 um 14:22 schrieb Kenichi Handa:

>> So again I see the file names (almost) correctly
>> (the composed characters are taken, as usual, from some arbitrary
>> fonts)
>
> 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 "«£".


Even without this new file I could see composed characters.

	(require 'ucs-normalize)
	ucs-normalize

or

	(load-library "ucs-normalize")
	t

in the new and still not installed GNU Emacs 23.1.50 makes no  
difference. The version from three weeks ago does not allow to  
separate the composed character's components, i.e., the text cursor  
cannot select this or that component, one step and it has reached the  
previous or next character. A difference I can see comes C-u C-x =:  
the line

  canonical-combining-class: 0 (Spacing, split, enclosing,  
reordrant, and Tibetan subjoined)

is removed from the output.


The composed character still is not taken from the default font.  
Could be one component is missing, ¨ – but it has the precomposed  
characters I usually use.

--
Greetings

  Pete

Treffen sich zwei Funktionen.
Sagt die eine: „Verschwinde oder ich differenzier' dich!“
Erwidert die andere: „Ätsch, ich bin exponentiell!“

Previous Next

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