Closed uliska closed 5 years ago
There's already one issue I noticed afterwards. While it works for lyluatex there will be a problem if another package requires the module: the OPTIONS
variable is a sigle object, so there are clashes.
I think I see the way to go forward but I have to leave now and can't test it for now.
I think this works now. I can successfully compile the manual as well as another document that uses both lyluatex and my own package making use of lyluatex-lib.
I don't see any objection, so I'm merging now (to avoid potential conflicts if we made other changes before merging).
This is an initial commit at factoring out commonly usable functionality to a separate module. For now I have moved all the local functions to a new file
lyluatex-lib.lua
that are unrelated tolyluatex
's actual work.I think there can be more code to be moved and reused from other packages/modules. One thing, though: I have the impression that the code factored out is the code that is totally unrelated to LilyPond scores but rather concerned with managing a Lua-based LaTeX package. If that's correct (I'm not too sure about my perception of these things) it might be something to consider to factor this out to a completely independent module/package that can be used from arbitrary packages (I think I would love to use the option handling functionality from arbitrary packages without including
lyluatex
(but maybe that's already possible like it is, simply assuming the package is installed?).I'm not sure if this Pull Request is intended to already be merged. I opened it to request your feedback @jperon, but of course you can merge it if you want. I have tested it with
make clean make manual
, so I assume there are no errors in it.If you think it is OK to move in that direction I would reorganize the file to separate the generic tools from those for option/package management.
NOTE: This commit includes the change made in #241, so basically it closes #241 (that last mention is to see if the autoclose feature works)