From xemacs-m  Mon Jun  2 03:18:24 1997
Received: from mail1-im.etl.go.jp (mail.etl.go.jp [192.50.105.9])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id DAA22574
	for <xemacs-beta@xemacs.org>; Mon, 2 Jun 1997 03:18:23 -0500 (CDT)
Received: from etlpom.etl.go.jp (etlpom.etl.go.jp [192.31.200.9]) by mail1-im.etl.go.jp (8.8.5/3.5Wpl1-96112918) with ESMTP
	id RAA07779; Mon, 2 Jun 1997 17:17:42 +0900 (JST)
Received: from etlken.etl.go.jp (etlken.etl.go.jp [192.31.197.11]) by etlpom.etl.go.jp (8.8.5/3.5Wpl4-ETL_MASTER) with SMTP id RAA03766; Mon, 2 Jun 1997 17:17:41 +0900 (JST)
Received: by etlken.etl.go.jp (SMI-8.6/6.4J.6-ETL.SLAVE)
	id RAA14445; Mon, 2 Jun 1997 17:19:11 +0900
Date: Mon, 2 Jun 1997 17:19:11 +0900
Message-Id: <199706020819.RAA14445@etlken.etl.go.jp>
From: Kenichi Handa <handa@etl.go.jp>
To: mrb@Eng.Sun.COM
CC: morioka@jaist.ac.jp, xemacs-beta@xemacs.org
In-reply-to: <199706020747.AAA02702@xemacs.eng.sun.com> (message from Martin
	Buchholz on Mon, 2 Jun 1997 00:47:37 -0700)
Subject: Re: no-conversion trashes compressed files
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>

   Date: Mon, 2 Jun 1997 00:47:37 -0700
   From: Martin Buchholz <mrb@Eng.Sun.COM>
   I agree that no-conversion is a better name for what XEmacs now calls
   binary.  And being compatible with Emacs 20 is a very good thing.  The
   name 'emacs-mule' seems silly to me, however, if it means the same
   thing as XEmacs's "no-conversion" - how can one guess what that
   means?  If 'emacs-mule' means that it is encoded in the internal
   representation, then it is something very different from XEmacs's
   "no-conversion".  After reading in a file with "no-conversion" in
   XEmacs, there are only Latin-1 characters in the buffer.

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

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

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

---
Ken'ichi HANDA
handa@etl.go.jp

