LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Monospaced Font
Show HTML Part by Default
Show All Mail Headers

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

Print Reply
David Kastrup <[log in to unmask]>
Wed, 22 Jan 2003 16:40:13 +0100
text/plain (139 lines)
        Frank Mittelbach <[log in to unmask]> writes:

> David Kastrup writes:

>  > The inputenc package is a vital part of LaTeX.
>
> is it? you seem to be very keen on disabling it with your
> interesting interpretation of locale support for TeX.

Then we appear not to understand one another one bit in this regard as
well.  I said that it is a bad idea to cripple TeX to 8-bit opacity by
forcing it to locale C by default, causing input letters to be
reported in error messages, log files and write statements to be only
written in ^^ notation.

Since I have not made a single statement in support of crippling
input transparency, but have focused on keeping people from crippling
output transparency, I fail to see that accusation hold.

>  > 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.
>
> it works perfectly without eTeX. what does not work is an extension
> of the concept (and one that is not extremely important) and that is
> what is under discussion here).

So it seems I have lost context.  I thought this was about inputenc
support for utf8, and for other inputenc matters where it would not
be convenient to have a transliteration that will only work in either
text or math mode.

>  > My original proposal of doing such a declaration for the next
>  > LaTeX release was violently opposed.
>
> you seem to have an understanding of violently that is quite
> different from mine. same for the the word "opposing".  if widely
> opposing for you means, there are people you do not agree 100% with
> your point of view and they express that or dicuss consequences,
> then i fear is is not getting you very far if you ever try to work
> with a team of people.

There were voices in strong opposition, and there were voices that
said one could do something like that, but that there was no
convincing reason that would actually require it.  That was where the
discussion basically petered off.  I did not say that I was violently
opposed by everybody, only that there _was_ opposition to that.
Heiko mentioned that e-TeX broke french.sty (which apparently
caught Bernard by surprise), so it would also seem apparent that this
was not the first time the matter was brought up.

Your own comment came about closest to admitting there was any merit
in my proposal.

> I wrote in reply to your policy thread:
>
> ----------------
>    > 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

This would appear to mean that one should avoid having LaTeX
explicitly break on eTeX (like french.sty purportedly does), but that
otherwise no course of action that would mandate it at some time
should be taken.

>    > 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 have to admit that I have not had kept the extent of b) in memory
here correctly.  I apologize for that.  It does, however, seem to
rule out having eTeX intrude in the LaTeX core.

>  > Now you propose to do something equivalent, only without prior
>  > warning, and actually without announcing it anywhere properly?
>
> i don't see that the dicussion concerning LICR used in math and the
> suggestion I brought forward for a possible package, are in any
> conflict with my earlier statements repeated above.

Then I am simply too stupid to get the context.  I thought this was
about utf8 inputenc support.  It seems I try to keep up with too many
discussions at once and get them mixed up.

I should better call it quits.

> there is however a proposal for a package that would use eTeX
> features (if possible)

But that would not be integrated with inputenc?

> it doesn't mean that such a statement needs to go out yesterday just
> because you think it should. In fact it should not, as it has a lot
> of implications for the good and worse and those need to be thought
> through further than 3 or 4 angry mails by you

Well, I brought the matter of eTeX up earlier on the list.  It did
not appear to start much thinking through.  It might reemerge at some
othe time.

So probably one should start collecting ideas why it would be a bad
idea to have a migration plan of LaTeX to eTeX, and why it could be a
good idea.

With regard to the good idea, we have
a) some inputenc problems
b) some programming features
   (\unless, \ifcsname, \protected, \everyeof, \splitdiscards,
   \grouplevel, \numexpr, \firstmarks and similar stuff all solve
   problems that are very ugly to work around otherwise).
c) limits (may I say "number of \dimen registers"?)

With regard to the bad idea, we have
a) it's a change
b) commercial vendors might have to work to support the change.

> i agree with you on the "soon", especially if your information on
> tetex is correct, which I assume is. but you could have parted with
> that earlier.

I have sent a message to the tetex-pretest list telling people that it
is possible that there would come a time when it would be appreciated
if using eTeX as default engine for "latex" might be reasonably easy
to do and that the way of achieving that should be well-documented.
teTeX already comes with a separate "elatex", but most TeX shells and
users of course will use "latex" instead.

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

ATOM RSS1 RSS2