David wrote > > But the question then arises: why e-TeX? Why not Omega, an > > e-TeX/Omega hybrid, . . . ? > > Because functionality present in e-TeX is desperately needed for > implementing more versatile output routines than the present, was > explicitly requested by LaTeX project team members and implemented > for their sake. well, to get some historical facts right :-) ... the LaTeX project never explicitly requested anything that is in eTeX and i don't think one can say it was put there for our sake. what happened was that some parts of eTex have been a sort of "reverse-engineering" of stuff that got solved in LaTeX + some functionality that the eTeX developers thought could be useful perhaps. I seriously doubt that there is much in terms of new functionailty that actually allows more functionalty in TeX. There are however some bits that make programming simpler and more straight forward. Speaking of what we "requested" from the eTeX team (but what was unfortunately never implemented due to the fact that eTeX development stopped) is recorded in: http://www.latex-project.org/papers/etex-meeting-notes.pdf and http://www.latex-project.org/papers/etex-math-notes.pdf > 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. 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, ... > In contrast, Omega is a moving target and widely undocumented. The > features specific to Omega are rather orthogonal to most of the > problems the LaTeX3 project is tackling. I second the nice phrase "widely undocumented" :-) but i disagree that the features specific to Omega are orthogonal to most problems that we try to tackle. 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. 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 - good parts of etex oldenburg notes - good parts of omega as of now - good parts of ... 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. for my part an eetex (ie etex+oldenburg) would do as a first step as well the benefit of just using etex however is fairly small (though it exists for new stuff) whether it is a good move to suggest for 2e is a different matter and that is what started this discussion. 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 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. > 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) > 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; 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. > In addition, one can't find out what additional primitives the core > would warrant if one never gets into a serious state, and one can't > get into a serious state if one choses to wait all the time for > non-existent features. > > I can tell you a dozen good reasons why it would be an excessively > bad idea to declare Omega the default TeX engine for LaTeX now. I agreed, but now is no here nor there. any default engine needs to be stable and maintained and basically feature frozen. whilst omega does not provide such stability it is not a candidate. > can't give you a single reason why e-TeX should not be declared the > default TeX engine for LaTeX _now_. not agreed (uncertain). 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. but then encouraging people to provide packages that use eTeX features might be a first step in this direction. frank