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
Condense Mail Headers

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

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Fri, 24 Jan 2003 01:59:31 +0100
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
7bit
In-Reply-To:
Content-Type:
text/plain; charset=us-ascii
From:
Frank Mittelbach <[log in to unmask]>
Parts/Attachments:
text/plain (81 lines)
David Kastrup writes:
 >
 > To put it bluntly: why would I need to persuade people like you? The

yes why? to put it bluntly: the style you show make me wonder if you are a
person one wishes to work with after all. isn't this possible with a bit more
politeness and less personal insults? please do not introduce such "rtfm idiot
it told you so" mentality into a discussion group that is essentially build on
mutal respect for each other.

Tim,

though i'm repeating David now partially, the reason why switching the
underlying engine would perhaps be a good move is that

 - it enables development of 2e packages that need it (and then work if you
   say latex foo.tex without problems, eg especially for people working with
   tex shells and can't simply replace latex by elatex on the command
   line---as they have none)

 - the switch is by now painless as it can be done in the big standard
   distributions, ie behind the scene and it doesn't affect any current
   usages, ie a current latex format on tex behaves like one on etex except
   that the latter can use my trace package properly or the new inpmath
   package (despite the open question of what happens with that)

 - it the major distributions would switch without harm it would be easier to
   later upgrade to an l3 kernel that actually makes use (already in the
   kernel) of etex primitives

 - i and others might be able to sleep longer and not work so late at night
   (see time :-) as our code requires less maintenance to work for you and
   others (that's the everest argument, just dealt with some nfss problem)

 - David could perhaps sleep better as he wouldn't need to worry about my or
   other peoples feet :-)

by the way, you too assuming you use a web2c based implementation have
switched engines several times without noticing, eg the pristine tex isn't
real tex any more these days at least on the command line it offers additional
features.

the main point for me against it is that i don't wish to give the impression
that a l3 would be necessarily based on etex, it will be based on more than
tex and the etex primitives are a good start as a requirement, so all this
could probably be explained in a suitable policy statement.



but coming back to my hurting foot, that David seems to be so concerned
about. i don't wish to remove his believe that his wisdom is the (only) reason
for triggering events, but this seems to be just another time of things
getting ripe and his famous plea for a policy is something that would have
happend for the next latex release even without him nagging, though perhaps
not to the extend that a suggestion to change the default engine would be part
of the proposal as it is now under discussion.

one thing however is quite certain for me. there will be no 2e kernel that
requires etex as a formatter, my intention is rather to make 2e essentially
frozen (except for severe bug fixes and fixes/extensions in 2e side packages)
with the next release and from then on only work on l3 development that will
going to use etex primitives (or even more if a suitable successor shows
up).

As part of this new work somebody might want to implement a new kernel that is
essentially 2e in features but using the better programming features of
etex. who knows, perhaps then people will switch from 2e to that new kernel
simply because that kernel has less (or different) known errors as the 2e
kernel has (most of them are called features these days:-).
however, i doubt it (especially that it would become fast enough a stable
production kernel to warrant promoting such a move) and i would undertake such
an excerise for other reasons if at all.

does the above helps you to understand (and perhaps even promote) what the
benefits for you would be?


good night

frank

ATOM RSS1 RSS2