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: Kenichi Handa <handa <at> m17n.org>
Cc: 4157 <at> debbugs.gnu.org
Subject: bug#4157: 23.1.50; faulty character characterisation for ä
Date: Wed, 26 Aug 2009 00:19:17 +0200

Am 24.08.2009 um 14:22 schrieb Kenichi Handa:

> 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 "«£".


When I copy a line from a dired buffer with a composed character  
taken from another font into *scratch* buffer and then apply on the  
marked file name ucs-normalize-HFS-NFC-region, then the foreign glyph  
is changed to one from the default font. Automatically this does not  
happen in dired buffer, although global-auto-composition-mode and  
auto-composition-mode are both t.

And ucs-normalize is auto-loaded!

--
Greetings
                                 <]
  Pete       o        __o         |__    o           recumbo
    ___o    /I       -\<,         |o \  -\),-%       ergo sum!
___/\ /\___./ \___...O/ O____.....`-O-'-()--o_________________
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.