From xemacs-m  Mon Jun  2 04:07:28 1997
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by xemacs.org (8.8.5/8.8.5) with SMTP id EAA23482
	for <xemacs-beta@xemacs.org>; Mon, 2 Jun 1997 04:07:27 -0500 (CDT)
Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id CAA05310; Mon, 2 Jun 1997 02:24:10 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id CAA18131; Mon, 2 Jun 1997 02:05:31 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id CAA19543; Mon, 2 Jun 1997 02:05:30 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id CAA02732; Mon, 2 Jun 1997 02:05:29 -0700
Date: Mon, 2 Jun 1997 02:05:29 -0700
Message-Id: <199706020905.CAA02732@xemacs.eng.sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Kenichi Handa <handa@etl.go.jp>
Cc: morioka@jaist.ac.jp, xemacs-beta@xemacs.org
Subject: Re: no-conversion trashes compressed files
In-Reply-To: <199706020819.RAA14445@etlken.etl.go.jp>
References: <o97d8q9i7ra.fsf@lspsun16.epfl.ch>
	<QQcruv17710.199705302020@crystal.WonderWorks.COM>
	<o973er3j0u9.fsf@lspsun16.epfl.ch>
	<s1c4tbju54e.fsf@mousa.jaist.ac.jp>
	<199706020747.AAA02702@xemacs.eng.sun.com>
	<199706020819.RAA14445@etlken.etl.go.jp>
X-Mailer: VM 6.31 under 20.3 XEmacs Lucid (beta3)
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>

>>>>> "Kenichi" == Kenichi Handa <handa@etl.go.jp> writes:

Kenichi> The name `emacs-mule' was chosen because it is what Emacs is now using
Kenichi> for the internal representation and is the same as what Mule is using.
Kenichi> But, Emacs will change the current internal representaion in the
Kenichi> future for supporting ISO10646 (this work will be done after merging
Kenichi> Mule is finished).  So, the name contains `-mule' for the moment.

Martin> After reading in a file with "no-conversion" in XEmacs, there are
Martin> only Latin-1 characters in the buffer.

Kenichi> ???  How the seqnece "\222\244\242" (internal representation of
Kenichi> Hiragana `A') is decoded when it is read by no-conversion?

The internal representation of buffer contents in XEmacs is generally
*NOT AVAILABLE* to the lisp programmer.  If configured --debug, then
an "internal" coding system is available, but it is intended only for
debugging XEmacs.  So there is normally no equivalent to Emacs-20's
"emacs-mule" coding system.  This is an intentional design decision.
The coding system for encoding elc files is "escape-quoted", an
extension of iso2022.

Ben Wing says, "Mule 2.3 exposes the implementation of charsets and leading
bytes in files saved in the internal format.  This makes it impossible
to make even simple internal changes such as re-arranging the
pre-defined charsets."  I personally have not investigated the Emacs
20 implementation deeply.

Martin

