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

Previous Next

Package: emacs;

Reported by: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>

Date: Sun, 16 Aug 2009 02:25:05 UTC

Severity: minor

Tags: notabug

Found in versions 27.0.50, 23.1.50

Done: Stefan Kangas <stefan <at> marxist.se>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Kenichi Handa <handa <at> m17n.org>
To: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
Cc: 4157 <at> debbugs.gnu.org
Subject: bug#4157: Re: bug#4157: 23.1.50; faulty character characterisation for ä
Date: Mon, 24 Aug 2009 21:22:20 +0900
In article <56EC0D72-D541-470F-9FAB-2F766BD45601 <at> Freenet.DE>, Peter Dyballa <Peter_Dyballa <at> Freenet.DE> writes:

> I finally managed to build a stable GNU Emacs! In ISO Latin-9/ISO  
> 8859-15 environment default-file-name-coding-system is utf-8 and file- 
> name-coding-system in nil, local in each of the visited dired buffers  
> (0 in mode-lines).

Ok, so dired is going to decode the output of ls by utf-8.

> So again I see the file names (almost) correctly  
> (the composed characters are taken, as usual, from some arbitrary  
> fonts) and the month date field as M\344r instead of Mär and the \344  
> character (4194276, #o17777744, #x3fffe4), although part of ISO  
> 8859-15, is supposed to be a raw byte and faultily declared as "not  
> encodable by coding system iso-latin-9-unix."

No, Emacs just tries to encode \344 by utf-8 and correctly
declared that it is not encodable by utf-8.

In article <jwvfxbjb8t1.fsf-monnier+emacsbugreports <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> So my guess was right: ls's output uses utf-8 for the filenames, but
> latin-1 for the date...

I think that is your case (latin-9 instead of latin-1).

Stefan also wrotes:

> which is why it's difficult for dired to do the
> right thing (it's not impossible, of course, but it's more work and
> dired is currently not setup for that).

How about making dired decode the filename part by
file-name-coding-system and the rest part by
default-process-coding-system?

By the way,

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

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



This bug report was last modified 5 years and 240 days ago.

Previous Next


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