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:
Wed, 22 Jan 2003 17:17:21 +0100
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
8bit
In-Reply-To:
<l03102800ba54558e389b@[130.239.20.144]>
Content-Type:
text/plain; charset=iso-8859-1
From:
David Kastrup <[log in to unmask]>
Parts/Attachments:
text/plain (69 lines)
        Lars Hellström <[log in to unmask]> writes:

> At 12.58 +0100 2003-01-22, David Kastrup wrote:
> >Yes.  You guys crack me up.  The inputenc package is a vital part of
> >LaTeX.  If it does not work well without eTeX and complains about this
> >with an appropriate warning, that means that non-eTeX-2 should
> >officially be declared deprecated with due warning time.
> >
> >My original proposal of doing such a declaration for the next LaTeX
> >release was violently opposed.
>
> An important difference between the suggestions is that you
> suggested that LaTeX should have a built-in uselessness (that
> prevented running it on non-e-TeX): you want to remove
> functionality.

Nonsense.  I wanted to have it _declared_ in 2003 that a LaTeX
installation should be running eTeX, and that non-eTeX was to be
considered obsolete, and that developers should no longer be confined
to not using eTeX if they wanted to have their packages working in a
conforming LaTeX installation with 2004.  "Removing functionality"
was never under discussion, just stopping to enforce never using
readily available functionality.

There are problems that are very hard to solve when one wants to
avoid eTeX.  It is my opinion that the work of the LaTeX team can
certainly invested better when they don't have to do three times the
work to make sure that new code will still work under old executables.

For example, one can easily see that supporting new input encodings
(like Unicode) reliably is much easier using eTeX.  The LaTeX team is
shooting itself in the foot by trying to cater to non-eTeX all the
time.  I was not even proposing stopping them (or rather os) shooting
themselves in the foot right now.  I was proposing a timeline for
stopping to shoot our feet.

> Certainly not before 2004, but nonetheless uselessness.

I consider it useless to cripple new development permanently by not
even allowing for a migration timeline.  The human and other resources
of the LaTeX team are awfully short.  One has to economize.  Ignoring
e-TeX is an inefficiency that in my personal opinion is too expensive
a luxury when one wants to get the problems solved that LaTeX faces
nowadays.  Some problems might be worked around with with Herculean
efforts: I am a TeX wizard myself, I know what it possible given
suitable recklessness.  Some problems can't.  But when a viable
solution exists, doing it the hard way is not the right way to do it
if the task is getting a job done.


> If one wants to convince people to use eTeX instead of TeX then I
> think a carrot is better than a whip. Whipping tends to make people
> want to run away.

We have had enough LaTeX developers run away because of being whipped
with bad code.  LaTeX internals are accessible only to wizards, and
that is partly a result of the refusal to revert to sane means where
insane ones are available.

How would \DeclareRobustCommand look if one used \protected?  And the
whole fragile protection business?  There are quite a few examples
where code is very complicated because of missing TeX internals.

I just propose a migration plan so that new developments might not be
similarly crippled.

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

ATOM RSS1 RSS2