<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Dear list,</p>
<p>I have a mix of a question and a suggestion regarding option
handling in Lua-based LaTeX packages.</p>
<p>I contributed to the development of the lyluatex package, whose
1.0 final has recently been uploaded to CTAN
(<a class="moz-txt-link-freetext" href="https://ctan.org/pkg/lyluatex">https://ctan.org/pkg/lyluatex</a> and
<a class="moz-txt-link-freetext" href="https://github.com/jperon/lyluatex">https://github.com/jperon/lyluatex</a>). The package makes extensive
use of options (package, global and per-entry options), and the
main developer has produced an impressive infrastructure to handle
these.</p>
<p>After I copied and adjusted the relevant code to some of my own
package I realized we should factor it out so I can access and
reuse the functionality from arbitrary packages, so we moved the
code to two separate Lua modules.</p>
<p>After the release I suggested going one step further and moving
the functionality in a *package* so after a simple \RequirePackage
there would be the relevant Lua tables available. When lyluatex is
loaded the helper modules are loaded implicitly.</p>
<p>However, now I think that the helper functionality is in no way
related to lyluatex and probably generally useful, and so the
questions are a) is that true? b) is that publicly available
already (oops)? and c) what would be the best way forward to make
it as useful as possible?</p>
<p>We have two modules:</p>
<ul>
<li>lyluatex-lib.lua
(<a class="moz-txt-link-freetext" href="https://github.com/jperon/lyluatex/blob/master/lyluatex-lib.lua">https://github.com/jperon/lyluatex/blob/master/lyluatex-lib.lua</a>)</li>
<li>lyluatex-options.lua
(<a class="moz-txt-link-freetext" href="https://github.com/jperon/lyluatex/blob/master/lyluatex-options.lua">https://github.com/jperon/lyluatex/blob/master/lyluatex-options.lua</a>)</li>
</ul>
<p>Probably the stuff in lyluatex-libs.lua is not really unique, and
we should rather investigate the lualibs package for existing
functionality and probably change the code to use that. However,
the option handling might be something that could be made
available separately to simplify the creation of Lua-based
packages for others as well. A user-oriented short description of
the functionality is in this section of the manual:
<a class="moz-txt-link-freetext" href="https://github.com/jperon/lyluatex/blob/master/lyluatex.md#option-handling-option-handling">https://github.com/jperon/lyluatex/blob/master/lyluatex.md#option-handling-option-handling</a>.<br>
An example of a package making use of the functionality is here:
<a class="moz-txt-link-freetext" href="https://github.com/uliska/lyluatexmp/blob/master/lyluatexmp.sty">https://github.com/uliska/lyluatexmp/blob/master/lyluatexmp.sty</a>.
Note that in line 43 a `lyluatex_options` object is available
through the implicit loading through lyluatex.
<a class="moz-txt-link-freetext" href="https://github.com/uliska/lyluatexmp/blob/master/lyluatexmp.lua">https://github.com/uliska/lyluatexmp/blob/master/lyluatexmp.lua</a>
then accesses the options' current values through the xmp_opts
table defined starting at
<a class="moz-txt-link-freetext" href="https://github.com/uliska/lyluatexmp/blob/master/lyluatexmp.sty#L44">https://github.com/uliska/lyluatexmp/blob/master/lyluatexmp.sty#L44</a></p>
<p>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`?</p>
<p>Thanks for any suggestions<br>
Urs<br>
</p>
<p><br>
</p>
</body>
</html>