Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Jan 2003 19:44:52 +0100 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id h06Iij6C013639 for ; Mon, 6 Jan 2003 19:44:50 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.27]) by relay.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h06IYpEV006598; Mon, 6 Jan 2003 19:34:51 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B5B3.B299EA00" 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 h064ACcS008642; Mon, 6 Jan 2003 19:28:21 +0100 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 5498 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 6 Jan 2003 19:28:21 +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 h06IILTk012631 for ; Mon, 6 Jan 2003 19:18:21 +0100 Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by relay.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h06IOmEV004911 for ; Mon, 6 Jan 2003 19:24:49 +0100 (MET) Received: from fwd02.sul.t-online.de by mailout09.sul.t-online.com with smtp id 18Vbvc-0002xz-04; Mon, 06 Jan 2003 19:24:48 +0100 Received: from localhost.localdomain (520018396234-0001@[217.80.157.144]) by fmrl02.sul.t-online.com with esmtp id 18VbvM-1sCoQCC; Mon, 6 Jan 2003 19:24:32 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h06IOUEp012306 for ; Mon, 6 Jan 2003 19:24:30 +0100 Received: (from dak@localhost) by localhost.localdomain (8.12.5/8.12.5/Submit) id h06IOUAh012302; Mon, 6 Jan 2003 19:24:30 +0100 In-Reply-To: <15897.49420.486809.50100@istrati.mittelbach-online.de> Lines: 163 References: <15897.10031.19948.331055@cs.anu.edu.au> <15897.49420.486809.50100@istrati.mittelbach-online.de> Return-Path: X-OriginalArrivalTime: 06 Jan 2003 18:44:52.0260 (UTC) FILETIME=[B2C19640:01C2B5B3] 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: Proposed change of policy Date: Mon, 6 Jan 2003 19:24:29 +0100 Message-ID: A X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Proposed change of policy Thread-Index: AcK1s7Lm86IUOiXLQpSgDAz71rwUig== From: "David Kastrup" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4401 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2B5B3.B299EA00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Frank Mittelbach writes: > I seriously doubt that there is much in terms of new functionailty > that actually allows more functionalty in TeX. \savingdiscards is one. It is pretty much necessary for sane replay and evaluation of special penalties. > > Instead of refusing to step forward until we can go as far as > > possible, we should concentrate on going as far as necessary, and > > e-TeX _is_ necessary and available. > > this is in fact at least partially true (and different from the > situation in 1998). these days eTeX *is* indeed more or less > generally available (but see below). in 1998 when the Oldenburg > meeting happened I (for my part) rejected the idea of moving to etex > as it was then, for the simple reason that > > a) it was not generally available for a large part of the community = (at > least not without hassle) and > > b) it did only provide benefits for the developers but no benefits > for the user as such. as a result people would have been (even > more) reluctant to switch. You are operating under the delusion that the average user is the one who is generating formats. It is the distribution vendors. > as i said i think the situation is better now, but one has to be > aware of the fact that there are in fact a large number of > commercial implementations around that do not have eTeX support on > board! and anybody who has done some support for publishing houses > will know that authors (especially) in the US often come along with > PCTeX, Y&Y, ... Well, then they need to get started at some time, and if one never changes the policies, they won't get started. > or rather I would like to rephase that: as it is today, that > statement is true, but as of today most of the programming and > functionality support that i would like to see in a successor of TeX > is also not part of eTeX (again see above paper on the Oldenburg > sessions). Now eTeX is dead or frozen as far as I can see, Omega is > not. Fine. So we have something to look forward to as the underlying machinery for LaTeX4. However, there are a lot of problems we would want to solve with LaTeX3. > Now you are right that a moving target is of not much use to LaTeX > either. For this reason we've been in close contact with the Omega > team to see if there could be a > maintained/moreorlessfrozen/documented/... Omega+- that has > > - good parts of etex e-OMEGA has just been announced by Bilotta. > within a reasonable short timeframe and see whether that could be > used to move further development to. whether that is possible is > something (I guess) this year will show. The output routine related stuff can't wait that long. It will take years until Omega is in a stable enough state that one can seriously consider running a stable LaTeX off it. > why do i think it may not be a good thing for 2e? > > because even though etex has a wider distribution these days, it has > not necessarily a wide enough distribution Which is why we need to declare a change of _policy_ instead of _starting_ with breaking compatibility. I think that a LaTeX2e successor should be possible based on e-TeX, and that the work on it would only to a quite small degree be wasted once the hypothetical situation of an ubiquitously available Omega sets in. > and it doesn't immediately offer features that make people die for > it, eg to take the trouble and change their installation. eg take > the protection (that is solved within LaTeX perhaps not perfectly > but it works, eTeX will make the internals work better (except that > it may not work at all as it did have a bug there) but from the > outside for the user nothing changes. Except that packages interact better and more of them become available as the programmers don't have to shoot themselves in the foot as much as now. > > The current ignorance of e-TeX is not merely hampering ongoing > > LaTeX3 efforts, it is also crippling people working on LaTeX2e > > packages. Even if LaTeX3 will be released in 10 years only, it > > is a shame not being able to work with e-TeX before. > > nobody hinders you to do that right now: you could in a package > check if eTeX is there and if not print out a rude message and > exit. that is what Martin called "etex aware" i guess. but it is > slighly different from changing the 2e kernel so that it dies on a > vanilla TeX and therefore perhaps on 1/5 of all TeX installations > (that are in real use) That is why I say one should as a first step declare a _policy_, and only at a later time take breakage into account. I am not saying that e-TeX 1998 will always be sufficient for everything, I am saying that it is insane not moving to a code base which is both very much established, available and stable, simply because it is not as much established and available than if one had made this move already. > > I am not talking about what users will be forced to use once > > LaTeX3 comes out. I am talking about what engine should be > > available to LaTeX2e users and upwards. > > so it seems to me that to answer this question really is to evaluate > if the concerns mentioned above are real or imaginary; They are real. I am working on critical edition work, and it will require eTeX. If I can't fold back the changes I am doing into the current LaTeX development, this work will get wasted. > also to evaluate if it would be important to actually have eTeX > support in the kernel. there is nearly nothing that really must be > done in a format (other than loading hyphenation patterns), thus > even an output routine could be loaded afterwards replacing the > current routine. If the base format does not contain the material to juggle insertions in and out of boxes via \split and similar stuff, it contains almost nothing. This stuff is hard core: it does not prescribe an output routine, but it manages all the resources necessary for the same. > > can't give you a single reason why e-TeX should not be declared > > the default TeX engine for LaTeX _now_. > > not agreed (uncertain). Progress needs first steps. > but to be honest, it is something i was considering a few weeks ago > at least for everything in the xpackage area. as for the 2e default > engine I have my reservations for the reasons outlined above. This is why I say one should declare an "obsolescence" phase. > but then encouraging people to provide packages that use eTeX > features might be a first step in this direction. 3/4 of all users will balk at replacing their standard formats and won't use packages that would require so, or that will only work when calling `elatex' as an executable name instead of `latex': it would require them to change their complete system and TeX shells and other stuff. This is something that requires very little actual work, but it is something the distribution vendors need to do. So we need to make this a policy. People are free to comply or not, but there will come a point of time when it might be better for them if they did so. It is only fair to give them due warning, and I want this warning out with the next LaTeX2e release. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ------_=_NextPart_001_01C2B5B3.B299EA00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Proposed change of policy

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

> I seriously doubt that there is much in terms of = new functionailty
> that actually allows more functionalty in = TeX.

\savingdiscards is one.  It is pretty much = necessary for sane replay
and evaluation of special penalties.

>  > Instead of refusing to step forward = until we can go as far as
>  > possible, we should concentrate on = going as far as necessary, and
>  > e-TeX _is_ necessary and = available.
>
> this is in fact at least partially true (and = different from the
> situation in 1998). these days eTeX *is* indeed = more or less
> generally available (but see below). in 1998 = when the Oldenburg
> meeting happened I (for my part) rejected the = idea of moving to etex
> as it was then, for the simple reason = that
>
>   a) it was not generally available = for a large part of the community (at
> least not without hassle) and
>
>   b) it did only provide benefits for = the developers but no benefits
>   for the user as such. as a result = people would have been (even
>   more) reluctant to switch.

You are operating under the delusion that the average = user is the one
who is generating formats.  It is the = distribution vendors.

> as i said i think the situation is better now, = but one has to be
> aware of the fact that there are in fact a large = number of
> commercial implementations around that do not = have eTeX support on
> board! and anybody who has done some support for = publishing houses
> will know that authors (especially) in the US = often come along with
> PCTeX, Y&Y, ...

Well, then they need to get started at some time, and = if one never
changes  the policies, they won't get = started.

> or rather I would like to rephase that: as it is = today, that
> statement is true, but as of today most of the = programming and
> functionality support that i would like to see = in a successor of TeX
> is also not part of eTeX (again see above paper = on the Oldenburg
> sessions). Now eTeX is dead or frozen as far as = I can see, Omega is
> not.

Fine.  So we have something to look forward to as = the underlying
machinery for LaTeX4.  However, there are a lot = of problems we would
want to solve with LaTeX3.

> Now you are right that a moving target is of not = much use to LaTeX
> either. For this reason we've been in close = contact with the Omega
> team to see if there could be a
> maintained/moreorlessfrozen/documented/... = Omega+- that has
>
>  - good parts of etex

e-OMEGA has just been announced by Bilotta.

> within a reasonable short timeframe and see = whether that could be
> used to move further development to. whether = that is possible is
> something (I guess) this year will show.

The output routine related stuff can't wait that = long.  It will take
years until Omega is in a stable enough state that = one can seriously
consider running a stable LaTeX off it.

> why do i think it may not be a good thing for = 2e?
>
> because even though etex has a wider = distribution these days, it has
> not necessarily a wide enough = distribution

Which is why we need to declare a change of _policy_ = instead of
_starting_ with breaking compatibility.  I think = that a LaTeX2e
successor should be possible based on e-TeX, and that = the work on it
would only to a quite small degree be wasted once the = hypothetical
situation of an ubiquitously available Omega sets = in.

> and it doesn't immediately offer features that = make people die for
> it, eg to take the trouble and change their = installation. eg take
> the protection (that is solved within LaTeX = perhaps not perfectly
> but it works, eTeX will make the internals work = better (except that
> it may not work at all as it did have a bug = there) but from the
> outside for the user nothing changes.

Except that packages interact better and more of them = become
available as the programmers don't have to shoot = themselves in the
foot as much as now.

>  > The current ignorance of e-TeX is not = merely hampering ongoing
>  > LaTeX3 efforts, it is also crippling = people working on LaTeX2e
>  > packages.  Even if LaTeX3 will = be released in 10 years only, it
>  > is a shame not being able to work = with e-TeX before.
>
> nobody hinders you to do that right now: you = could in a package
> check if eTeX is there and if not print out a = rude message and
> exit. that is what Martin called "etex = aware" i guess. but it is
> slighly different from changing the 2e kernel so = that it dies on a
> vanilla TeX and therefore perhaps on 1/5 of all = TeX installations
> (that are in real use)

That is why I say one should as a first step declare a = _policy_, and
only at a later time take breakage into = account.

I am not saying that e-TeX 1998 will always be = sufficient for
everything, I am saying that it is insane not moving = to a code base
which is both very much established, available and = stable, simply
because it is not as much established and available = than if one had
made this move already.

>  > I am not talking about what users will = be forced to use once
>  > LaTeX3 comes out.  I am talking = about what engine should be
>  > available to LaTeX2e users and = upwards.
>
> so it seems to me that to answer this question = really is to evaluate
> if the concerns mentioned above are real or = imaginary;

They are real.  I am working on critical edition = work, and it will
require eTeX.  If I can't fold back the changes = I am doing into the
current LaTeX development, this work will get = wasted.

> also to evaluate if it would be important to = actually have eTeX
> support in the kernel. there is nearly nothing = that really must be
> done in a format (other than loading hyphenation = patterns), thus
> even an output routine could be loaded = afterwards replacing the
> current routine.

If the base format does not contain the material to = juggle insertions
in and out of boxes via \split and similar stuff, it = contains almost
nothing.  This stuff is hard core: it does not = prescribe an output
routine, but it manages all the resources necessary = for the same.

>  > can't give you a single reason why = e-TeX should not be declared
>  > the default TeX engine for LaTeX = _now_.
>
> not agreed (uncertain).

Progress needs first steps.

> but to be honest, it is something i was = considering a few weeks ago
> at least for everything in the xpackage area. as = for the 2e default
> engine I have my reservations for the reasons = outlined above.

This is why I say one should declare an = "obsolescence" phase.

> but then encouraging people to provide packages = that use eTeX
> features might be a first step in this = direction.

3/4 of all users will balk at replacing their standard = formats and
won't use packages that would require so, or that = will only work when
calling `elatex' as an executable name instead of = `latex': it would
require them to change their complete system and TeX = shells and other
stuff.

This is something that requires very little actual = work, but it is
something the distribution vendors need to do.

So we need to make this a policy.  People are = free to comply or not,
but there will come a point of time when it might be = better for them
if they did so.  It is only fair to give them = due warning, and I want
this warning out with the next LaTeX2e = release.

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

------_=_NextPart_001_01C2B5B3.B299EA00--