Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Wed, 22 Jan 2003 13:26:02 +0100 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id h0MCPx6C008546 for ; Wed, 22 Jan 2003 13:26:00 +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 h0MC8kM4013253; Wed, 22 Jan 2003 13:08:46 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C211.6D132900" 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 h0LN04JD021675; Wed, 22 Jan 2003 13:01:35 +0100 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 7297 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Wed, 22 Jan 2003 13:01:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id h0MBpY5f026285 for ; Wed, 22 Jan 2003 12:51:34 +0100 Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by relay.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h0MBwgSa007360 for ; Wed, 22 Jan 2003 12:58:42 +0100 (MET) Received: from fwd02.sul.t-online.de by mailout03.sul.t-online.com with smtp id 18bJWk-00065x-09; Wed, 22 Jan 2003 12:58:42 +0100 Received: from localhost.localdomain (520018396234-0001@[62.226.11.210]) by fmrl02.sul.t-online.com with esmtp id 18bJWe-2CKxPcC; Wed, 22 Jan 2003 12:58:36 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h0MBwYi5002413 for ; Wed, 22 Jan 2003 12:58:34 +0100 Received: (from dak@localhost) by localhost.localdomain (8.12.5/8.12.5/Submit) id h0MBwWfY002409; Wed, 22 Jan 2003 12:58:32 +0100 In-Reply-To: <15918.32649.326340.239302@istrati.mittelbach-online.de> Lines: 49 References: <15915.60496.798501.907773@lin2.idris.fr> <15915.64379.146524.772099@istrati.mittelbach-online.de> <15916.8635.946195.989212@istrati.mittelbach-online.de> <15916.14608.340151.43815@istrati.mittelbach-online.de> <15917.9945.473122.219613@istrati.mittelbach-online.de> <15918.32649.326340.239302@istrati.mittelbach-online.de> Return-Path: X-OriginalArrivalTime: 22 Jan 2003 12:26:02.0521 (UTC) FILETIME=[6D62A890:01C2C211] X-Sender: 520018396234-0001@t-dialin.net User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: -2.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_GNUS_UA Content-class: urn:content-classes:message Subject: Re: LICR objects in math Date: Wed, 22 Jan 2003 12:58:31 +0100 Message-ID: A X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: LICR objects in math Thread-Index: AcLCEW1+MGUD77/ySgqQvFjTZNu7Qw== From: "David Kastrup" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4469 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2C211.6D132900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Frank Mittelbach writes: > anyway, all that struggling nicely vanishes if one uses eTeX version > 2. so why not do that and have a package that tests for eTeX and if > it finds out that it doesn't run under eTeX emits a warning (at the > beginning and end of the run), eg > > \typeout{********************************************************^^J% > *^^J% > * WARNING: ^^J% > *^^J% > * \@spaces The inpmath package was written to support 8bit^^J% > > questions: > > a) any obvious problems with this approach? Yes. You guys crack me up. The inputenc package is a vital part of LaTeX. If it does not work well without eTeX and complains about this with an appropriate warning, that means that non-eTeX-2 should officially be declared deprecated with due warning time. My original proposal of doing such a declaration for the next LaTeX release was violently opposed. Now you propose to do something equivalent, only without prior warning, and actually without announcing it anywhere properly? If we will agree that a good implementation needs to rely on eTeX and that inputenc will give out a warning like that, then it would be not only fair to announce officially that LaTeX should use eTeX starting with the next release if available, but also announce this information on tex-implementors at the very least in order to give the commercial parties a chance to come up with something for their customers when the next LaTeX release happens. And we would want to give out notice to people like Thomas Esser also: the next teTeX release is imminent, and occurs typically only every few years or so. At the very least it would be very desirable to have a fit-for-dummies way or instructions to change the LaTeX engine to eTeX for the case that people want to upgrade their LaTeX in June. This should happen before teTeX-final. So we better come fast to grips about that matter. Even if it is just a "likely" thing to happen, notice should get out in time. And that would mean very soon. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ------_=_NextPart_001_01C2C211.6D132900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: LICR objects in math

        Frank = Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG> writes:


> anyway, all that struggling nicely vanishes if = one uses eTeX version
> 2. so why not do that and have a package that = tests for eTeX and if
> it finds out that it doesn't run under eTeX = emits a warning (at the
> beginning and end of the run), eg
>
> = \typeout{********************************************************^^J%
> *^^J%
> * WARNING: ^^J%
> *^^J%
> * \@spaces The inpmath package was written to = support 8bit^^J%
>
> questions:
>
>  a) any obvious problems with this = approach?

Yes.  You guys crack me up.  The inputenc = package is a vital part of
LaTeX.  If it does not work well without eTeX = and complains about this
with an appropriate warning, that means that = non-eTeX-2 should
officially be declared deprecated with due warning = time.

My original proposal of doing such a declaration for = the next LaTeX
release was violently opposed.  Now you propose = to do something
equivalent, only without prior warning, and actually = without
announcing it anywhere properly?

If we will agree that a good implementation needs to = rely on eTeX and
that inputenc will give out a warning like that, then = it would be not
only fair to announce officially that LaTeX should = use eTeX starting
with the next release if available, but also announce = this information
on tex-implementors at the very least in order to = give the commercial
parties a chance to come up with something for their = customers when
the next LaTeX release happens.

And we would want to give out notice to people like = Thomas Esser also:
the next teTeX release is imminent, and occurs = typically only every
few years or so.  At the very least it would be = very desirable to
have a fit-for-dummies way or instructions to change = the LaTeX engine
to eTeX for the case that people want to upgrade = their LaTeX in
June.  This should happen before = teTeX-final.

So we better come fast to grips about that = matter.  Even if it is
just a "likely" thing to happen, notice = should get out in time.  And
that would mean very soon.

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

------_=_NextPart_001_01C2C211.6D132900--