From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) Newsgroups: gmane.mail.mew.general,gmane.emacs.devel Subject: [mew-int 01591] Re: windows 1252 Date: Wed, 05 Nov 2003 00:55:02 +0900 (JST) Message-ID: <20031105.005502.58143677.kazu@iijlab.net> References: <87llqzuvaj.fsf@tleepslib.sk.tsukuba.ac.jp> <20031104.111334.60445673.kazu@iijlab.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1067961337 28630 80.91.224.253 (4 Nov 2003 15:55:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2003 15:55:37 +0000 (UTC) Original-X-From: mew-int-return-1591-gmmg-mew-int=m.gmane.org@mew.org Tue Nov 04 16:55:33 2003 Return-path: Original-Received: from mew2.iijlab.net ([202.232.15.102]) by deer.gmane.org with smtp (Exim 3.35 #1 (Debian)) id 1AH3Wm-00035t-00 for ; Tue, 04 Nov 2003 16:55:33 +0100 Original-Received: (qmail 29877 invoked by uid 7800); 4 Nov 2003 15:55:27 -0000 Mailing-List: contact mew-int-help@mew.org; run by ezmlm Precedence: bulk List-Unsubscribe: Original-Received: (qmail 29865 invoked from network); 4 Nov 2003 15:55:27 -0000 Original-Received: from unknown (HELO omgo.iij.ad.jp) (202.232.30.157) by 202.232.15.102 with SMTP; 4 Nov 2003 15:55:27 -0000 Original-Received: from jc-smtp.iij.ad.jp ([192.168.176.35]) by omgo.iij.ad.jp (8.12.10/8.12.9) with ESMTP id hA4FtIf2012960; Wed, 5 Nov 2003 00:55:18 +0900 (JST) Original-Received: from localhost (jc-ssh.iij.ad.jp [192.168.174.22]) by jc-smtp.iij.ad.jp (8.12.10/8.12.9) with ESMTP id hA4FsmhI024308; Wed, 5 Nov 2003 00:54:48 +0900 (JST) Original-To: emacs-devel@gnu.org, mew-int@mew.org In-Reply-To: X-Mailer: Mew version 4.0.61 on Emacs 21.3.50 / Mule 5.0 (SAKAKI) X-ML-Name: mew-int X-Mail-Count: 01591 Xref: main.gmane.org gmane.mail.mew.general:516 gmane.emacs.devel:17685 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:17685 From: Stefan Monnier Subject: [mew-int 01590] Re: windows 1252 > > (1) Backgourd compatibility to non-Mule Emacsen. > > > Non-Mule Emacsen use 8bit as ISO-8859-1. Thus, to share the > > cache among Mule Emacsen and non-Mule Emacsen, we need to > > character set whose 8bit is ISO-8859-1. > > utf-8 would be ideal here. Not correct. UTF-8 is compatible to US-ASCII but not to ISO-8859-1. That is, U0000-U007f is encoded to 0x00-0x0f while U0080-U00FF is encoded to two 8bit bytes (110xxxxx 10xxxxxx). > > (2) Co-exist of Emacs and XEmacs. > > > The 'emacs-mule coding-system is not appropriate since XEmacs > > has a different internal representation from Emacs'one. Note > > Emacsen use different 'emacs-mule coding-system among > > versions. > > iso-2022 would be the answer here. Yes, ctext is one instance of the ISO-2022 framework. > It's unfortunate, but I guess it makes sense. > It should be possible to make ctext-with-extensions work for your case. To support a new character set in ctext, we only need to register a new escape sequence. The new ctext is forward compatible, and backward compatible if the new character set is not encoded. So, we don't need a new coding-system name, I think. > BTW, windows-1252 should internally be turned into a mix of chars from > various charsets and they should (hopefully) all be encodable directly in > ctext, so I'm not sure what is your exact problem. Could you describe what > currently happens with windows-1252 and what you'd like to see instead ? As I said, I don't know windows-1252 well and I don't know the current ctext can encode all windows-1252 characters. I would like to know correct information about this. --Kazu