Am Tue, 4 Jun 2019 16:28:47 +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. I didn't try to imply that the package is useless, only that there are probably not so many packages who can use it. From all the packages I created, maintain or I'm somehow involved currently only one is pure luatex (luaotfload) and this has no option handling. > 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. Sure I understand this, and it is useful, see e.g. siunitx for an implementation with tex macros: in siunitx you can set options as package options, or with \sisetup, or locally in optional arguments. -- Ulrike Fischer https://www.troubleshooting-tex.de/
