LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
David Kastrup <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Mon, 6 Jan 2003 19:24:29 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (164 lines)
        Frank Mittelbach <[log in to unmask]> 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

ATOM RSS1 RSS2