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 #15 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>, 4157 <at> debbugs.gnu.org
Subject: Re: bug#4157: 23.1.50; faulty character characterisation for
 ä
Date: Tue, 18 Aug 2009 10:09:22 +0900

In article <57B19222-57FF-40C8-8C94-8D19E1281D14 <at> Freenet.DE>, Peter Dyballa <Peter_Dyballa <at> Freenet.DE> writes:

> When I launch GNU Emacs in an ISO Latin environment (env  
> LC_CTYPE=de_DE.ISO8859-15 LANG=de_DE.ISO8859-15 /usr/local/bin/ 
> emacs-23.1.50 -Q &) and display in dired a directory with entries  
> from some month of March the "Mär" abbrevation for the German month  
> name "März" is displayed as M\344r. C-u C-x = on this \344 reveals:

> 	        character: \344 (4194276, #o17777744, #x3fffe4)
> 	preferred charset: eight-bit (Raw bytes 128-255)
> 	       code point: 0xE4
> 	           syntax: w 	which means: word
> 	      buffer code: #xE4
> 	        file code: not encodable by coding system =
> iso-latin-9-unix
> 	          display: no font available

> The dired buffer has a 0 as encoding indicator. In ISO Latin 1 or 15  
> encodings LATIN SMALL LETTER A WITH DIAERESIS is \344 = 228 = 0xE4 =>  U 
> +00E4 a valid character and not some raw "eight-bit" entity. Could be  
> this prevents proper display:

Please show the value of default-file-name-coding-system and
file-name-coding-system.

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