From xemacs-m  Fri Jan 10 15:14:43 1997
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5])
          by xemacs.org (8.8.4/8.8.4) with SMTP
	  id PAA25148 for <xemacs-beta@xemacs.org>; Fri, 10 Jan 1997 15:14:42 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA04213; Fri, 10 Jan 1997 13:13:52 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id NAA01582; Fri, 10 Jan 1997 13:13:48 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id NAA29345; Fri, 10 Jan 1997 13:13:46 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id NAA27982; Fri, 10 Jan 1997 13:13:46 -0800
Date: Fri, 10 Jan 1997 13:13:46 -0800
Message-Id: <199701102113.NAA27982@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko
 <morioka@jaist.ac.jp>
Cc: Sudish Joseph <sudish@mindspring.com>,
        XEmacs beta <xemacs-beta@xemacs.org>, tm-en@chamonix.jaist.ac.jp,
        Steven L Baur <steve@miranova.com>,
        KOBAYASHI Shuhei <shuhei-k@chamonix.jaist.ac.jp>
Subject: Re: tm problem with xemacs-20.0b34 
In-Reply-To: <199701101433.XAA22239@mikan.jaist.ac.jp>
References: <199701062040.MAA11071@xemacs.eng.sun.com>
	<199701101433.XAA22239@mikan.jaist.ac.jp>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.100)
Content-Type: text/plain; charset=ISO-2022-JP-2

>>>>> "MT" == MORIOKA Tomohiko <MORIOKA> writes:

MT> [1  <multipart/mixed>]
MT> [1.1  <text/plain; US-ASCII (7bit)>]
>>>>> In <199701062040.MAA11071@xemacs.eng.sun.com> 
>>>>>> "Martin" = Martin Buchholz <mrb@Eng.Sun.COM> wrote:

Martin> If a file contains *any* non-latin1 characters, then the
Martin> 20.0-mule byte-compiler will write it in a format only
Martin> comprehensible by 20.0/mule.  In this case the only non-latin1
Martin> characters are in a comment on line 99.  So if you remove that
Martin> comment, then tm-edit.el byte-compiled by 20.0-mule will work
Martin> on 20.0-latin1.

MT>   ISO 8859-1 characters may occur same problems, because internal
MT> representation of ISO 8859-1 characters are different between
MT> non-internationalized XEmacs and XEmacs/mule.

When xemacs/mule creates a .elc file, it checks if all the characters
in the .el file are either ascii or latin-1.  If so, it uses the
'binary coding system to encode the .elc file.  Such an .elc file is
readable by xemacs without mule support.  If other kinds of characters
are found, the 'escape-quoted coding system (a modification of
iso-2022-8) is used to encode the .elc file, and this can only be read
by xemacs-mule.

MT>   Anyway I will delete non-ASCII characters of tm-edit.el.

Thanks.

MT> [1.2  <text/plain; ISO-2022-JP-2 (7bit)>]

Martin> Tomohiko: Looking at latex-math-symbol.el, I see that the
Martin> characters for \\leq and \\le are identical (both glyphs look
Martin> like a \\leq), and the character set for these is
Martin> korean-ksc5601.  The intention is probably that characters
Martin> from japanese-jisx0208 are selected, as with other characters
Martin> in this file.

MT>   I think \\leq and \\le are same in TeX.

MT>   JIS X0208-1983 has `$B!e(B' (\leqq of AMS TeX), and `$B!f(B' (\geqq of AMS
MT> TeX) but don't has `$(C!B(B' and `$(C!C(B' so I used KS C5601.

Now I understand.

Martin

