> While working on my class, I’ve been thinking about the available tools and
> where 2e is necessary vs. what can be replaced with L3 methods.
> I know that there isn’t a consensus on how boxes should work, so things like
> `\parbox` and friends should still be used (unless coffins happen to work
> better for a given use case).
> However, I think there’d be no harm in providing an L3 interface for dims and
> skips. I know that the 2e kernel already provides tools for this, and so an L3
> interface would have some redundancies. I think an `xskips` package would still
> be useful because:
> 1. it would provide more tools than 2e does; and
> 2. it would harmonize with the other L3 design-level interfaces.
that's a good question what harmonizes with L3 design-level interface.
Remember that we think of the designer level of more or less free of
programming, i.e., you make declarations (possibly using CamelCase
syntax but you don't "program" (or if you do, because the features you
are looking for require that it would be in a clearly separate section
that is actually package code only not separated out --- and then that
kind of code would be direct expl3).
So what is the purpose for example of \VerticalSpace? would it have a
natural place to live and if so why?
I guess our ask here would be use cases for the commands you proposed to
get a feeling whether they should and if so in what form they should be
provided but not embark on making a copy of the expl3 code interfaces
1-2-1 into CamelCase unless we all agree on seeing a good reason for it.
There are of course boundary cases, eg
a function for setting length parameters should naturally support
evaluations of its value argument (which right now \newlength doesn't
offer (unless you load calc.
But already the distinction between skips and dimens (that exist on the
programming level but not on the 2e user level in the setters) is
something to ponder. An I would be interested to see examples why the
distinction os sensible on the designer level (I'm not convinced it is)
I mean, why shouldn't there be a single set of design-level setters.
As for allocation, to what extend are they needed on the design level?
Aren't they only needed when you are actually asking for some programmed
> I have attached the raw .sty code which contains what I think are appropriate
> tools for the designer level. Of course, this would become a proper .dtx file
> with documentation and examples.
So rather than documenting that suggestion, I would ask for convincing
examples for each of the proposed functions that are design tasks that
should live in a class file rather than programming tasks that should
live in package/modules that offer building blocks for titles building
blocks for headings etc etc.
I'm not saying none of them are, maybe some are the right choice for the
design level, but instead of embarking on providing stuff that we later
regret, let us first better understand the needs. So if you have the
time I would very much look forward in seeing how you intend to use each
and every of these functions.
ps while we are at it, uses of \parbox and friends (or coffins) would be
also very much of interest. where do you use them and how ...