From xemacs-m  Mon Jan  6 14:41:45 1997
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5])
          by xemacs.cs.uiuc.edu (8.8.4/8.8.4) with SMTP
	  id OAA29863 for <xemacs-beta@xemacs.org>; Mon, 6 Jan 1997 14:41:41 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA19641; Mon, 6 Jan 1997 12:40:54 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id MAA00703; Mon, 6 Jan 1997 12:40:49 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id MAA09826; Mon, 6 Jan 1997 12:40:48 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id MAA11071; Mon, 6 Jan 1997 12:40:47 -0800
Date: Mon, 6 Jan 1997 12:40:47 -0800
Message-Id: <199701062040.MAA11071@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Sudish Joseph <sudish@mindspring.com>,
        MORIOKA Tomohiko <morioka@jaist.ac.jp>
Cc: XEmacs beta <xemacs-beta@xemacs.org>, tm-en@chamonix.jaist.ac.jp,
        Steven L Baur <steve@miranova.com>
Subject: Re: tm problem with xemacs-20.0b34
In-Reply-To: <yviasp4gavb5.fsf@atreides.mindspring.com>
References: <199701051502.KAA08423@homer.sccon.com>
	<yviasp4gavb5.fsf@atreides.mindspring.com>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.100)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Sudish" == Sudish Joseph <sudish@mindspring.com> writes:

Sudish> andreas  writes:
>> when sending email under vm i get the following error...

>> (error "Byte code stack underflow (byte compiler bug), pc 38")

>> i then compiled the latest tm and stuck it in a directory and loaded
>> it and all is well so it appears the tm in the distribution is not
>> working properly...

Sudish> If you re-byte-compile lisp/tm/tm-edit.el, the distributed version
Sudish> works fine.  As Steve pointed out, that file is compiled with a
Sudish> mule-enable 20.0.

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

Note that other problems are also likely to arise, since the tm
included with 20.0-mule may make assumptions about having mule
facilities available at run time.

Tomohiko:  could you please ensure that .el files included as part of
TM, which will potentially be used with both mule and non-mule
xemacsen, only contain latin-1 characters?  tm/tm-edit.el is the only
file currently known to be a problem.  The other file containing
non-latin1 characters is latex-math-symbol.el, but in this case the
characters are actually functional - i.e. I would expect this file to
only be useful with a mule-enabled XEmacs.

BTW: For you all you math people out there:  latex-math-symbol.el is
one reason to use Mule even if you only care about the English
language.  It's nice to have characters for PI and
less-than-or-equal-to.

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

Martin

