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]>
Subject:
From:
Frank Mittelbach <[log in to unmask]>
Date:
Thu, 4 Mar 1999 00:10:23 +0100
In-Reply-To:
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
text/plain (81 lines)
Martin writes in reply to Lars:

 > >That's fine by me, I'm in no hurry in this matter. BTW, is the writing of
 > >such packages a privilege for the LaTeX3 project team, or may the public
 > >contribute as well?
 >
 > You're welcome. They decide only what consitutes LaTeX3.

first of all it is THEM not They at least to some people and to the crossword
in the LaTeX Graphics companion :-)

more importantly, we are eager to have "the public" contribute; most people
now members of THEM started off by incoccently contributing (and now
feeling bad about being drawn into the all that work that is involvedi n
maintaining LaTeX while doing development as well :-) so feel warned.

there is the argument that we (ie the project members) shut out others and
their good ideas by keeping tight control on 2e these days and rejecting a lot
of good ideas on obscure arguments.

Yes we are doing that but not on obscure arguments but in our opinion because
of the need of the user community for stability and exchangabilities of LaTeX
sources.  i recently had the pleasure to write a class files for the AIP and
they asked me whether i could support their user queries on that class as well
(for a while). to my horror i found that the major problems all their users
accountered were kernel changes in 2e between 94 and now. in essense i got hit
by more or less any feature i used in the current release that was not there
in one or the other earlier releases. as it turned out a lot of users had no
problem to get a missing support files, eg graphics not installed, keyval not
available, or calc not available, but faced with the fact that sometime in
1996 we added the feature that \MakeUppercase can be used in the declaration
of a heading turned out to be a major problem as all such users where unable
to get their department install a more uptodate 2e (in time at least)

this compatibility issue is the main reason why we don't support incremental
extensions to the kernel but want to see them in packages up to a point where
there is enough to make a clean step forward with enough new features wanted
by the community to make them change to an extensively new kernel.

with experimental ideas this is even more important.

but what goes for 2e as it is now and should not be taken as the message that
we do want to implement everything ourselves or are not open to good ideas
even if we say, NO, not into the 2e kernel.

-----------------------------------------------------

i hope that David Kastrup is on this list as this is relevant to the somewhat
unfortunate (and in the end unecessary personal) discussion in latex/2969

we are NOT working on the principles (attributed to big blue) that "if you
cant fix it call it a feature by documenting it" or even worse if you can't be
bothered to fix it even if somebody tells you how ...

... but we are working on the principle that in 2e designed interfaces should
not not be extended in the (2e) kernel and thereby making different
maintenance releases of 2e incompatible to each other.

with respect to pr/2969 (which you may want to look up in the public bug
database to better understand what i'm talking about): i think that the idea
of being able to specify key/val type arguments to a package somehow, is
interesting and worth having --- in what form is something that i think is
debatable ---- but not (in our opinion) by silently changing the defined
semantics of the \usepackage command by making the kernel smarter to support
"code" as part of the optional argument of \usepackage instead of the
advertised (though definitely limited) concept of "a comma separated list of
abstract option names, where an option name is a seven bit visible ascii
string from without any LaTeX control chars"

that interface could and perhaps should be smartened up but not via a kernel
change at this stages but via a package (like keyval that smartens up optional
arguments in the graphics suite of packages) as the latter ensures
compatibilities and allows a user to get a missing package if needed without
too much problems.

comments welcome

good night or rather good morning

frank

ATOM RSS1 RSS2