Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 02:09:46 +0100 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id h0O19h6C015026 for ; Fri, 24 Jan 2003 02:09:44 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.27]) by relay2.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h0O0xitt024500; Fri, 24 Jan 2003 01:59:44 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C345.48B86900" 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 h0NN047B011966; Fri, 24 Jan 2003 01:52:24 +0100 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 7592 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Fri, 24 Jan 2003 01:52:24 +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 h0O0qO5f013889 for ; Fri, 24 Jan 2003 01:52:24 +0100 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by relay.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h0O0xbXM017440 for ; Fri, 24 Jan 2003 01:59:37 +0100 (MET) Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 18bsC0-0002vg-00 for LATEX-L@listserv.uni-heidelberg.de; Fri, 24 Jan 2003 01:59:36 +0100 Received: from [80.129.2.11] (helo=istrati.mittelbach-online.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 18bsBz-0002pL-00 for LATEX-L@listserv.uni-heidelberg.de; Fri, 24 Jan 2003 01:59:36 +0100 Received: (from frank@localhost) by istrati.mittelbach-online.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id h0O0xVW28854; Fri, 24 Jan 2003 01:59:31 +0100 In-Reply-To: References: <15915.60496.798501.907773@lin2.idris.fr> <200301231843.18419.tim@birdsnest.maths.tcd.ie> <200301232130.53333.tim@birdsnest.maths.tcd.ie> Return-Path: X-Mailer: VM 6.96 under Emacs 20.7.1 X-OriginalArrivalTime: 24 Jan 2003 01:09:46.0491 (UTC) FILETIME=[490354B0:01C2C345] X-Authentication-Warning: istrati.mittelbach-online.de: frank set sender to frank@mittelbach-online.de using -f X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: -0.7 () IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,X_AUTH_WARNING Content-class: urn:content-classes:message Subject: Re: proposed change of policy Date: Fri, 24 Jan 2003 01:59:31 +0100 Message-ID: A<15920.36851.541750.964940@istrati.mittelbach-online.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: proposed change of policy Thread-Index: AcLDRUkscSE9zJP1TRi+ojKMW4ERiQ== From: "Frank Mittelbach" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4485 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2C345.48B86900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 ------_=_NextPart_001_01C2C345.48B86900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: proposed change of policy

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

------_=_NextPart_001_01C2C345.48B86900--