LATEX-L Archives

Mailing list for the LaTeX3 project


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
Mailing list for the LaTeX3 project <[log in to unmask]>
Wed, 4 May 2011 14:02:34 -0400
Mailing list for the LaTeX3 project <[log in to unmask]>
Barbara Beeton <[log in to unmask]>
TEXT/PLAIN (62 lines)
re engine-specific adjustments to packages,

    > As for
    > amsmath, that's still maintained by the AMS, and I believe they're
    > currently working on an update to that at the moment -- it would be
    > best to contact them directly. (I'm not sure who the best contact
    > there would be.)

the update is nearing the top of the list,
but, sadly, hasn't been scheduled yet, and
will surely not be ready for tex live 2011.

    (the ams have a tech-support address.)

that's always the best address to use.  i'm
usually the person who responds, but mail
to this address is archived and it's also
available to everyone in the group, so if
one of us is in timbuctu, someone else can
address problems quickly.

    in answer to philipp's question i would doubt that the project has the
    wherewithal to dictate how people should write things.  there were fine
    words spoken, on these lines -- discussing programming style, mostly, at
    the introduction of latex 2e.  those fine words were, by and large,
    ignored; and back then the only "different" engine we had in play was
    tex 2.*

we also have an aversion to writing things
to address engines we have no likelihood
of using, or solve problems that aren't
likely to come up in any book or journal
that we publish.  (that's because such
things are very difficult to test; we
really don't have that kind of resources.
i'm simply in awe of the job the tex live
gang is able to do along these lines.)

that being said, if a report or request
comes in with (1) a compelling argument
why it is needed, (2) a full example or
examples, stated clearly and precisely,
and (3) either a code suggestion or a
well thought out description of how the
change can be accomplished without fouling
up anything else, then it is more likely
to get looked at with favor.

for example, in the course of the update,
we intend to look at the package mathtools
and a few others that have addressed known
problems in amsmath, and also intend to
give full credit to the people who solved

    so my rule of thumb would be, fixes _should_ be present in packages or
    the kernel, as appropriate, but one should accept that occasionally a
    "tidy-up" package is going to be needed.

we're with you, robin.
						-- bb