Received: from webgate.proteosys.de (mail.proteosys-ag.com [62.225.9.49]) by lucy.proteosys (8.11.0/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id f19DiBH03979 for ; Fri, 9 Feb 2001 14:44:11 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f19DiBd17760 . for ; Fri, 9 Feb 2001 14:44:11 +0100 Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f19Di5M05607 for ; Fri, 9 Feb 2001 14:44:05 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0929E.61D1C780" Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.8.56]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id OAA13733 for ; Fri, 9 Feb 2001 14:44:05 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f19Di4M05593 for ; Fri, 9 Feb 2001 14:44:04 +0100 (MET) Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <7.32ABA377@mail.listserv.gmd.de>; Fri, 9 Feb 2001 14:43:58 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 488256 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Fri, 9 Feb 2001 14:43:59 +0100 Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id OAA18300 for ; Fri, 9 Feb 2001 14:43:57 +0100 (MET) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id OAA15588 for ; Fri, 9 Feb 2001 14:43:57 +0100 Received: from abel.math.umu.se (abel.math.umu.se [130.239.20.139]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f19Dhvu09859 for ; Fri, 9 Feb 2001 14:43:57 +0100 (MET) Received: from [130.239.20.144] (mac144.math.umu.se [130.239.20.144]) by abel.math.umu.se (8.9.2/8.9.2) with ESMTP id OAA30506; Fri, 9 Feb 2001 14:42:09 +0100 (CET) In-Reply-To: <14978.34274.931619.388835@ux28.nets.de.eds.com> References: <14968.6710.114015.220264@ux28.nets.de.eds.com> <200101292234.RAA14964@pluto.math.albany.edu> <14967.8829.903878.620595@istrati.zdv.uni-mainz.de> <200101310003.BAA02073@peano.cs.uni-dortmund.de> <14967.46479.253389.421142@istrati.zdv.uni-mainz.de> Return-Path: X-Sender: lars@abel.math.umu.se x-mime-autoconverted: from quoted-printable to 8bit by relay.urz.uni-heidelberg.de id OAA18302 Content-class: urn:content-classes:message Subject: Re: inputenc -> text+math Date: Fri, 9 Feb 2001 14:43:55 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: =?iso-8859-1?Q?Lars_Hellstr=F6m?= Sender: "Mailing list for the LaTeX3 project" To: "Multiple recipients of list LATEX-L" Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 3773 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0929E.61D1C780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 12.41 +0100 2001-02-08, Frank Mittelbach wrote: > > I don't follow you here. If the primitive isn't changed (which is = what I > > suggested) then everything which works today will continue to work = (not > > bomb), whereas if it is changed things may certainly bomb. By = providing a > >no it is the other way around. if, say, via inputenc we would be able >to specify that pressing the key a-umlaut generates \"a in text and >\ddot a in math (hope that exists :-) then using that in an array like = macro >which doesn't handle the checking correctly, you will end up with \"a >inside math and that will bomb. thus you would need to update all such >uses of \halign to use \latex@halign istead. Exactly what happens depend on how the text \"a is implemented (with the = T1 implementation and CM math the character simply is lost with no error message, whereas with OT1 implementation the \accent might well get TeX = to believe that you've lost a $), but I don't think the errors are serious enough to qualify as a "bomb" (at a Mac, a "bomb" is the last error = message before the system dies). Certainly these errors should be fixed (if possible), but one can live with them. On the other hand, I think that = the error caused by an \edef\@tempa{\halign to \the\dimen@} with \halign = being the mathtext redefinition rather than the primitive can qualify as a = bomb. > > fixed equivalent of the primitive, but not actually replacing it, = package > > writers can change their code to take advantage of these new macros = and > > thus have their code work in cases it previously didn't, whilst = unchanged > > code would continue to behave as it used to (most of the time work, = but > > fail in the odd cases discussed here). > >the problem is that these aren't "odd" cases really. not when you go >and try to make every keyboard character usable everywhere. I was thinking more in the lines of odd =3D "rarely occuring in existing documents". > > PS: Pity Donald's solution didn't work. TeX probably ought to have = been in > > the "no mode" (like when expanding the text for a \write) when it is > > looking for \noalign or \omit; then there would have been a test. > >probably but even then it would be a kind of horrible test, wouldn't = it? >since there is no \ifnomode Is \ifhmode\else \ifvmode\else \ifmmode\else \relax \fi\fi\fi that horrible? There are much fewer tokens than in \@inmathwarn. Lars Hellstr=F6m ------_=_NextPart_001_01C0929E.61D1C780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: inputenc -> text+math

At 12.41 +0100 2001-02-08, Frank Mittelbach = wrote:
> > I don't follow you here. If the primitive = isn't changed (which is what I
> > suggested) then everything which works = today will continue to work (not
> > bomb), whereas if it is changed things may = certainly bomb. By providing a
>
>no it is the other way around. if, say, via = inputenc we would be able
>to specify that pressing the key a-umlaut = generates \"a in text and
>\ddot a in math (hope that exists :-) then using = that in an array like macro
>which doesn't handle the checking correctly, you = will end up with \"a
>inside math and that will bomb. thus you would = need to update all such
>uses of \halign to use \latex@halign = istead.

Exactly what happens depend on how the text \"a = is implemented (with the T1
implementation and CM math the character simply is = lost with no error
message, whereas with OT1 implementation the \accent = might well get TeX to
believe that you've lost a $), but I don't think the = errors are serious
enough to qualify as a "bomb" (at a Mac, a = "bomb" is the last error message
before the system dies). Certainly these errors = should be fixed (if
possible), but one can live with them. On the other = hand, I think that the
error caused by an \edef\@tempa{\halign to = \the\dimen@} with \halign being
the mathtext redefinition rather than the primitive = can qualify as a bomb.

> > fixed equivalent of the primitive, but not = actually replacing it, package
> > writers can change their code to take = advantage of these new macros and
> > thus have their code work in cases it = previously didn't, whilst unchanged
> > code would continue to behave as it used to = (most of the time work, but
> > fail in the odd cases discussed = here).
>
>the problem is that these aren't "odd" = cases really. not when you go
>and try to make every keyboard character usable = everywhere.

I was thinking more in the lines of odd =3D = "rarely occuring in existing
documents".

> > PS: Pity Donald's solution didn't work. TeX = probably ought to have been in
> > the "no mode" (like when = expanding the text for a \write) when it is
> > looking for \noalign or \omit; then there = would have been a test.
>
>probably but even then it would be a kind of = horrible test, wouldn't it?
>since there is no \ifnomode

Is \ifhmode\else \ifvmode\else \ifmmode\else \relax = \fi\fi\fi that
horrible? There are much fewer tokens than in = \@inmathwarn.

Lars Hellstr=F6m

------_=_NextPart_001_01C0929E.61D1C780--