bug#4157: 23.1.50; faulty character characterisation for ä

[Peter Dyballa]

Am 19.08.2009 um 02:23 schrieb Kenichi Handa:

> Ah, I found this code in mule-cmds.el.
>
>   (if (eq system-type 'darwin)
>       ;; The file-name coding system on Darwin systems is always  
> utf-8.
>       (setq default-file-name-coding-system 'utf-8)
>
> I don't remember why that code exists.  If the comment is
> wrong (i.e. there's no need of treating darwin specially
> here), the attached patch should solve the problem.

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). 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." In the variant launched  
with UTF-8 this date field is displayed as Mär and this *obviously  
composed* ä described correctly as ä (228, #o344, #xe4) and taken to  
be displayed from an iso10646-1 encoded font. The buffer (and file)  
code is described as UTF-8 C3A4: #xC3 #xA4 (encoded by coding system  
utf-8-unix).

--
Greetings

  Pete

We also sponsor National Invisible Chronic Illness Awareness Week  
annually in September.
Join the millions