From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/45726 Path: main.gmane.org!not-for-mail From: Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai =?iso-8859-15?q?Gro=DFjohann?=) Newsgroups: gmane.emacs.gnus.general Subject: Re: locale ISO-8859-15, UTF-8 and mail... Date: Fri, 19 Jul 2002 09:19:39 +0200 Sender: owner-ding@hpc.uh.edu Message-ID: References: <87it3e2pzr.fsf@tzone.org> <878z49dnk3.fsf@tzone.org> <87bs94vk9w.fsf@tzone.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1027063419 23825 127.0.0.1 (19 Jul 2002 07:23:39 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 19 Jul 2002 07:23:39 +0000 (UTC) Cc: ding@gnus.org Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17VS70-0006Bz-00 for ; Fri, 19 Jul 2002 09:23:38 +0200 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 17VS44-0002bA-00; Fri, 19 Jul 2002 02:20:37 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 19 Jul 2002 02:21:01 -0500 (CDT) Original-Received: from sclp3.sclp.com (qmailr@sclp3.sclp.com [209.196.61.66]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id CAA12801 for ; Fri, 19 Jul 2002 02:20:46 -0500 (CDT) Original-Received: (qmail 28585 invoked by alias); 19 Jul 2002 07:20:18 -0000 Original-Received: (qmail 28580 invoked from network); 19 Jul 2002 07:20:17 -0000 Original-Received: from waldorf.cs.uni-dortmund.de (129.217.4.42) by gnus.org with SMTP; 19 Jul 2002 07:20:17 -0000 Original-Received: from lothlorien.cs.uni-dortmund.de (lothlorien [129.217.19.67]) by waldorf.cs.uni-dortmund.de with ESMTP id g6J7Jjb23328; Fri, 19 Jul 2002 09:19:45 +0200 (MES) Original-Received: from lucy.cs.uni-dortmund.de (lucy [129.217.19.80]) by lothlorien.cs.uni-dortmund.de id JAA20779; Fri, 19 Jul 2002 09:19:39 +0200 (MET DST) Original-Received: by lucy.cs.uni-dortmund.de (Postfix, from userid 6104) id ADE463B221; Fri, 19 Jul 2002 09:19:39 +0200 (CEST) Original-To: fabien@tzone.org (Fabien =?iso-8859-1?q?Ni=F1oles?=) Mail-Followup-To: fabien@tzone.org (Fabien =?iso-8859-1?q?Ni=F1oles), ?=@ls6.cs.uni-dortmund.de, ding@gnus.org In-Reply-To: <87bs94vk9w.fsf@tzone.org> (fabien@tzone.org's message of "18 Jul 2002 16:44:11 -0400") Original-Lines: 58 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.3.50 (i686-pc-linux-gnu) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:45726 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:45726 fabien@tzone.org (Fabien Ni=F1oles) writes: >>>>>> "Kai" =3D=3D Kai Gro=DFjohann w= rites: > > Kai> I don't understand. What does `W M c' have to do with > Kai> latinX-disp.el? > > Nothing. There seems to have two "bugs" here: > > 1- Gnus seems to defined it's own buffer-display-table instead of > using the standard-display-table. Since latinX-disp.el simply > modify the standard-display-table to be effective, it doesn't seems > to work in gnus (at least v5.9.0 that I used here). What does Gnus use that display table for? Maybe it's used for something useful. But maybe Gnus should inherit from the standard display table, and then frobbing that first with latinX-disp should do the trick. > 2- I isolate the other bug (the \201 or \216 character add before > every high-bit set character in multibyte environment) to a bug in > the coding-system. To test it just evaluate this: > > (decode-coding-string "=E9l=E8ve" 'iso-8859-1) =3D> "\216=E9l\216=E8ve" i= n latin-1 environment. The documentation for decode-coding-string says that it is required for the string to be encoded in the given coding system. Maybe your string is in iso-8859-15 and not iso-8859-1. If you give decode-coding-string some Japanese and tell it to decode as iso-8859-1, it won't be surprising that you get garbage, either. \216\151 is the internal Emacs representation (the Mule encoding) of that accented character in Latin-9. \201\151 would be the internal representation of the same character in Latin-1. You can type C-u C-x =3D on the =E9 character to verify whether it is in iso-8859-1. Hm. Hm. Also, I think that the function has been misapplied. decode-coding-string and encode-coding-string are for converting between external and internal representations. So, (decode-coding-string X 'iso-8859-1) takes a sequence X of bytes encoded as iso-8859-1 and returns a string encoded in Emacs' internal encoding. But you were passing not a sequence of bytes encoded in iso-8859-1, you were passing a Lisp string encoded in Emacs' internal encoding. And that encoding happens to use \216\151 for the =E9 character, so that's what you get... Maybe you can use vector to create a proper sequence of bytes. Or you get the bytes from an I/O operation (input, to be specific). kai --=20 A large number of young women don't trust men with beards. (BFBS Radio)