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 #65 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: Re: bug#4157: 23.1.50; faulty character characterisation for
 ä
Date: Tue, 25 Aug 2009 09:46:50 +0900

In article <AB00A4BE-E1DF-45F4-8953-23B2F7E551F9 <at> Freenet.DE>, Peter Dyballa <Peter_Dyballa <at> Freenet.DE> writes:

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

Even if your buffer has the char sequence "a" and "¨", "¨"
is displayed on top of "a" and cursor movement treats those
two characters atomically as if there's a single 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.

That's the point.  utf-8-hfs converts the sequence "a" and
"¨" to a single character "ä" on decoding, and breaks down
"ä" to "a" and "¨" on encoding.

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

Which font is selected for the character "ä"?  It seems to
be a bug if the font is not your default font.

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