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: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 4157 <at> debbugs.gnu.org
Subject: bug#4157: 23.1.50; faulty character characterisation for ä
Date: Sat, 22 Aug 2009 10:50:53 +0200
Am 22.08.2009 um 06:09 schrieb Stefan Monnier:

>> 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:
>
> Hmm... that looks like a problem in dired: the file names in the  
> output
> of `ls' should follow file-name-coding-system, whereas the rest of the
> output seem to use locale-coding-system.  Coudl you check if that's
> indeed the case:
> - create a file from the Finder using accented latin-1
>   chars, as well as non-latin-1 chars).
> - look at it in your dired and tell us what you see.

In both locales the *file names* are correct and also detected as  
containing "composed characters," it's a problem with the file's  
month date. In the ISO-Latin encoding the ä character is not  
recognised as that entity and part of the ISO Latin encoding, but as  
something strange which can only be displayed in octal  
representation. In UTF-8 this does not happen.

Isearch for example finds the \344 characters only as C-s C-q 3 4 4  
RET, while the character ä cannot be found (because composed, of a  
and ¨ and therefore a search for a succeeds, in both locales).

>
> On a Darwin system, I very warmly recommend to stick to utf-8 coding
> systems for everything, since it should avoid such problems.
>

Yes, you're right. I was trying to work on a problem with a "Carbon  
Emacs" ...

--
Greetings

  Pete

One cannot live by television, video games, top ten CDs, and dumb  
movies alone.
				– Amiri Baraka, 1999






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

Previous Next


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