Am 04.06.19 um 15:45 schrieb Ulrike Fischer:
Am Tue, 4 Jun 2019 11:37:31 +0200 schrieb Urs Liska:
To reiterate the question: Is this approach to handling options
something that already exists (so we shouldn't have bothered with the
implementation in the first place)? If not am I right with the
assumption that it would be a good idea to make it available as a
generic package, say `luaoptions`?
I only looked very briefly at the description so perhaps missed a
point. key-val-syntax is certainly used a lot by various packages,
but normally packages are written so that they can be used with more
than one engine, so a key-val-system that requires luatex as engine
is probably useful only for a small number of packages.
This is of course true but probably looks at the issue from the wrong
direction.
Yes, we do have a solution that depends on Lua. But this is because our
whole package totally relies on Lua to perform its work. Making parts of
our machinery available outside of the context of our package should
make sense even if it is limited to other luatex packages. (By extension
of that argument you could also say: why make a LaTeX package available,
which will not be useful to any InDesign user?)
The aspect that seems to make the option handling in the package useful
is that it's not simply an implementation of key-value package options
but an integrated solution to handling options on the package, the
global, and the per-item level. Think of a package that provides an
environment to include graphics and draw a graphical frame around (in
the sense of a phyiscal “real wooden“ oder “plastic” or ”aluminium”
frame). With a package option `frame-style` one of the predefined styles
is selected. In our package you can use that package option, change it
“from here on” with `\setframeoption{frame-style}{louvre}` so that
option value will be in place from now on. Or you can override it
locally like `\begin{artframe}[frame-style=moma]`. In the Lua part of
the package where the frame is actually cretaed you can simply access it
through e.g. frameoptions['frame-style'], or from the TeX side with
\directlua{frameoptions['frame-style']}. New packages that want to build
on that (or rather use the functionality) have very little work to set
up the custom handling of the package's option handling.
Does that make things clearer?
Best
Urs
