Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Mon, 20 Jan 2003 19:16:10 +0100 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id h0KIG86C000858 for ; Mon, 20 Jan 2003 19:16:09 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.27]) by relay2.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h0KI2vAL026281; Mon, 20 Jan 2003 19:02:58 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C0B0.01FE1100" Received: from listserv (listserv.uni-heidelberg.de [129.206.100.27]) by listserv.uni-heidelberg.de (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id h0K3Js87000694; Mon, 20 Jan 2003 18:55:33 +0100 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 7613 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 20 Jan 2003 18:55:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id h0KHtX5f009755 for ; Mon, 20 Jan 2003 18:55:33 +0100 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.189]) by relay2.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h0KI2cAL026198 for ; Mon, 20 Jan 2003 19:02:38 +0100 (MET) Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 18agFo-0008Kb-00 for LATEX-L@listserv.uni-heidelberg.de; Mon, 20 Jan 2003 19:02:36 +0100 Received: from [80.129.5.232] (helo=istrati.mittelbach-online.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 18agFo-0000si-00 for LATEX-L@listserv.uni-heidelberg.de; Mon, 20 Jan 2003 19:02:36 +0100 Received: (from frank@localhost) by istrati.mittelbach-online.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id h0KHxir24846; Mon, 20 Jan 2003 18:59:44 +0100 In-Reply-To: References: <15915.60496.798501.907773@lin2.idris.fr> <15915.64379.146524.772099@istrati.mittelbach-online.de> <15916.8635.946195.989212@istrati.mittelbach-online.de> Return-Path: X-Mailer: VM 6.96 under Emacs 20.7.1 X-OriginalArrivalTime: 20 Jan 2003 18:16:10.0817 (UTC) FILETIME=[027ABB10:01C2C0B0] x-mime-autoconverted: from quoted-printable to 8bit by listserv.uni-heidelberg.de id h0KHtX5f009756 X-Authentication-Warning: istrati.mittelbach-online.de: frank set sender to frank@mittelbach-online.de using -f X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: -2.3 () EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,X_AUTH_WARNING Content-class: urn:content-classes:message Subject: Re: LICR objects in math Date: Mon, 20 Jan 2003 18:59:44 +0100 Message-ID: A<15916.14608.340151.43815@istrati.mittelbach-online.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: LICR objects in math Thread-Index: AcLAsAKXMr4MxW1PQmyV24Mnq8rSWQ== From: "Frank Mittelbach" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4452 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2C0B0.01FE1100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David Kastrup writes: > > a) this doesn't help for LICR objects like \" as they potentially = execute > > \accent and that bombs in math > > Nope. We would have the case where \"a has a proper letter > equivalent. In that case we would write the following (excuse the > illegal notation > > \def{\"a}{\ifmmode \relax \ifmmode \ddot a\else =E4\fi\else =E4\fi} nope nope (imho:-) that's for the case where \"a is precisely *not* executing an \accent = but is actually a glyph in the current font (so that we evaluate to a \char and therefore get an active math definition in the first place) > > b) and even if \"a expands to a \chardef then the chardef number > > depends on the outer fontencoding so might vary from case to case > > That's the real problem. second real problem > How about squashing this particular problem with > \protected\def{\"a}{\ifmmode ...}? yes, that is indeed possible a way to go (with eTeX version 2 that is) i think i did say last night that etex doesn't havesomething to stop = scanning for \omit andthe like, but my memory played tricks on me. it did not have such a thing in version 1 but with version 2 \protected = was extended to do exactly that stop the scan of an \omit so that would be one point in favour of an eTeX based solution, as = suggested in the policy discussion frank ------_=_NextPart_001_01C2C0B0.01FE1100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: LICR objects in math

David Kastrup writes:

 > >  a) this doesn't help for LICR = objects like \" as they potentially execute
 > >  \accent and that bombs in = math
 >
 > Nope.  We would have the case where = \"a has a proper letter
 > equivalent.  In that case we would = write the following (excuse the
 > illegal notation
 >
 > \def{\"a}{\ifmmode \relax \ifmmode = \ddot a\else =E4\fi\else =E4\fi}

nope nope (imho:-)

that's for the case where \"a is precisely *not* = executing an \accent but is
actually a glyph in the current font (so that we = evaluate to a \char and
therefore get an active math definition in the first = place)


 > >  b) and even if \"a expands = to a \chardef then the chardef number
 > >  depends on the outer = fontencoding so might vary from case to case
 >
 > That's the real problem.

second real problem

 > How about squashing this particular problem = with
 > \protected\def{\"a}{\ifmmode = ...}?

yes, that is indeed possible a way to go (with eTeX = version 2 that is)

i think i did say last night that etex doesn't = havesomething to stop scanning
for \omit andthe like, but my memory played tricks on = me.

it did not have such a thing in version 1 but with = version 2 \protected was
extended to do exactly that stop the scan of an = \omit

so that would be one point in favour of an eTeX based = solution, as suggested
in the policy discussion

frank

------_=_NextPart_001_01C2C0B0.01FE1100--