David Kastrup writes:
 >         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.

:-) in that case you better play with it first; this is not entirely humorous,
there are problems with the current implementation of that (and other parts
that appear to be useful when reading the documentation only.

as for the rest of your message, please reread again what i wrote, in
several points you have misunderstood what i said, or so it seems to me.

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

my argument has nothing to do with generating formats. but you don't buy a new
TeX or change to a different installation just because the internals force you
to without no benefit.

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

changing policy by supporting the use of etex is one thing and perhaps a good
thing, the policy of breaking latex use on vanilla tex is a different one

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

possibly, though not likely, pdftex and etex have matured faster and the
features we are looking for could be implemented reasonably fast as well.

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

would it? it is unfortunately quite possible.

but you can also argue this is a two-way situation, if there is a reasonable
clear set of target goals (implementation features) with a roadmap to
implement them on one hand (call it eetex if you like with the orthogonal
omega bits ignored if you prefer that) then getting those implemented would
help latex development while at the same time might help eetex maturing

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

is it possible that you disagree with yourself here?

when you commented on me saying something about policy isprobably okay but not
putting stuff into the kernel you claimed:

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

anyway etex is a minimum that doesn't help much but i agree a successor should
have at least that (perhaps even with corrected algorithms :-) but that is a
policy for 2e extensions not necessarily for a 2e kernel

i have the impression that you do a bit of mixing up

  2e kernel + 2e extensions

  2e kernel + experimental 3e packages

  3e prototype kernel

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

well, you know the trouble from your work on ctt, but users don't care if
programmers shoot themselves, that's an unfortunate truth. anyway it is
certainly no harm in steering people in the right direction.

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

fine, i don't think i ever expressed a problem with that. it seems to me
(personally) quite a good move to a) encourage people to use etex features in
packages as well as b) formally suggesting that a complete LaTex installation
should provide for supporting such a usage.

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

now that seems to me something different again. here our backgrounds and
experiences seems to differ quite a lot from mine. 2e nearly died because we
forced the use of T1 encoded fonts into the distribution and a large
proportion of the user base (writing only english) saw no need to switch to
that new system.

so again, are you talking 2e base or are you talking experimental packages?
the latter would at some point have a proto-type kernel that then indeed also
would only run under an extended TeX (whatever flavor). but it seems to me
that here you are already thinking again of a kernel for 2e using etex.

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

i understand that for your commision you are interested in using etex features
and of course it would be nicer to have some of it in the current kernel but
there i would draw the line (if there are no new arguments coming along)

on the other hand, what do you mean by not being able to fold things back into
the LaTeX development? i wouldn't see that following. as i said in my previous
mail, for xpackages i see no problem whatsoever to use etex except that i
don't think a lot of it is of much use.

by the way, i was talking about my concerns :-)


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

sure but that does not mean you default the kernel but you can default new
development.

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

ahh and you think they are more likely to do that if ltnewsxx says we consider
the machine for latex being etex????

i don't. i do see a chance for a) encouraging development in that direction as
well as talking to vendors in parallel (the latter preferably by having
support from groups like DANTE etc) on the other hand for that formal switch i
would still like to switch to something better than etex

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

it does on installations where there is nothing like etex

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


reasonable request, with the "this" in "make this a policy" in my opinion
still a bit vague.

frank