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
Show All Mail Headers

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

Print Reply
Subject:
From:
Stephan Hennig <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Mon, 13 Jul 2015 21:37:30 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (36 lines)
Am 13.07.2015 um 18:23 schrieb Joseph Wright:

> We are not unmindful of the problem of code that works with multiple
> formats!

I'm sure you aren't.


> The luatebase package is loaded with plain TeX and is the common way to
> allocate resources.

Pointing to the luatexbase package reminds me on the mess^Wwealth of
key-value packages for (La)TeX.  I've never looked at any of those just
because there's so many to choose from.  For package contributors,
having functionality scattered throughout many similar packages is
really bad.  A package designer, basing on allocation in the LaTeX
kernel and later realizing that (part of) the package can be abstracted
from LaTeX has an additional burden of looking at alternative allocation
mechanisms.


> There are a variety of possible approaches where we either make it
> 'aware' of kernel changes or provide a new format-neutral package
> which incorporates the proposed kernel code when used with plain.

I'm in favour of a format-neutral package, which is pulled into the
(LaTeX) format.  It's a trade-off between format maintainer's and
package contributor's burden.  From the point of view of a format
maintainer, there a danger such centrally shared package being less
stable than desired.  But let's see.  If a format-agnostic allocation
package doesn't work out (technically or socially), any format
maintainers can fork that package later still.  Why fork today?

Best regards,
Stephan Hennig

ATOM RSS1 RSS2