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 f18B5WH29991 for ; Thu, 8 Feb 2001 12:05:32 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f18B5Wd12972 . for ; Thu, 8 Feb 2001 12:05:32 +0100 Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f18B5V722124 for ; Thu, 8 Feb 2001 12:05:31 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C091BF.0DA3E600" Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.8.57]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id MAA03866 for ; Thu, 8 Feb 2001 12:05:31 +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 mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f18B5T722115 for ; Thu, 8 Feb 2001 12:05:30 +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.E12E23AD@mail.listserv.gmd.de>; Thu, 8 Feb 2001 12:05:23 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 488042 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Thu, 8 Feb 2001 12:05:25 +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 MAA16197 for ; Thu, 8 Feb 2001 12:05:24 +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 MAA22414 for ; Thu, 8 Feb 2001 12:05:25 +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 f18B5Ou25132 for ; Thu, 8 Feb 2001 12:05:24 +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 MAA12802; Thu, 8 Feb 2001 12:03:38 +0100 (CET) In-Reply-To: <14977.48072.895815.829777@istrati.zdv.uni-mainz.de> 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 MAA16198 Content-class: urn:content-classes:message Subject: Re: inputenc -> text+math Date: Thu, 8 Feb 2001 12:05:23 +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: 3745 This is a multi-part message in MIME format. ------_=_NextPart_001_01C091BF.0DA3E600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 22.19 +0100 2001-02-07, Frank Mittelbach wrote: > > One variant would be to start offering LaTeX-variants of \halign and > > \valign which (i) has less corny syntax, (ii) takes care to prevent = errors > > of the kind discussed, and (iii) might offer a few extra features = (e.g. > > calc-like syntax for \tabskip glue specifications or something; I = don't > > know if that might be useful). What I'm thinking of is that you = could write > > something like > >Lars, > >while a suggestion like this would perhaps be an improvement for = package/class >writers it wouldn't solve the update problem i was talking about; and = if you >rely on code only working correctly if no straight \halign is arround >accepting arbitrary text, then this is a real problem. > > find /cdrom/texmf/tex/latex -type f -exec grep -l halign {} \; > >alone gives you 67 packages/classes that have \halign in their code = (well to >be exact have "halign" somewhere in their text :-), many many more = would be >out there and all of them would suddenly bomb if not updated 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 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). Lars Hellstr=F6m 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. ------_=_NextPart_001_01C091BF.0DA3E600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: inputenc -> text+math

At 22.19 +0100 2001-02-07, Frank Mittelbach = wrote:
> > One variant would be to start offering = LaTeX-variants of \halign and
> > \valign which (i) has less corny syntax, = (ii) takes care to prevent errors
> > of the kind discussed, and (iii) might = offer a few extra features (e.g.
> > calc-like syntax for \tabskip glue = specifications or something; I don't
> > know if that might be useful). What I'm = thinking of is that you could write
> > something like
>
>Lars,
>
>while a suggestion like this would perhaps be an = improvement for package/class
>writers it wouldn't solve the update problem i = was talking about; and if you
>rely on code only working correctly if no = straight \halign is arround
>accepting arbitrary text, then this is a real = problem.
>
> find /cdrom/texmf/tex/latex -type f -exec grep = -l halign {} \;
>
>alone gives you 67 packages/classes that have = \halign in their code (well to
>be exact have "halign" somewhere in = their text :-), many many more would be
>out there and all of them would suddenly bomb if = not updated

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
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).

Lars Hellstr=F6m

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.

------_=_NextPart_001_01C091BF.0DA3E600--