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 #85 received at 4157 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 4157 <at> debbugs.gnu.org
Subject: Re: =?ISO-8859-1?Q?Re:_bug#4157:_23.1.50;_faulty_character_character?= =?ISO-8859-1?Q?isation_for_=E4?=
Date: Thu, 27 Aug 2009 10:50:33 +0200

Am 27.08.2009 um 08:52 schrieb Kenichi Handa:

> I have no idea why it doesn't work in your environment.
>
>> And ucs-normalize is auto-loaded!
>
> When is it loaded?
>


Actually never! There are just precautions taken. When I deliberately  
set file-name-coding-system to utf-8-hfs in my init file, GNU Emacs  
stopped to initialise with an error message about an undefined  
encoding. So ucs-normalize obviously was not loaded. I added a  
(require 'ucs-normalize) – and it works! It works exceptionally well:  
i-search for ä or æ or ø in file names works.

That's really good work!


What I wonder is why so many different font encodings are used when  
characters are described. Wouldn't it make sense to use an iso10646-1  
encoding in an UTF-8 environment for characters from 8-bit ISO  
encodings? Wouldn't it free resources when less fonts are used? Or is  
it my fault that I include definitions for ISO encodings in my font set?

--
Greetings

  Pete

Government is actually the worst failure of civilized man. There has  
never been a really good one, and even those that are most tolerable  
are arbitrary, cruel, grasping and unintelligent.
				– H. L. Mencken

Previous Next

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