On Thu, Oct 20, 2016 at 12:17 PM, Patrick Gundlach <[email protected]> wrote: > While I'd really appreciate a "no TeX mode", I don't have any problems with > this setup. It works just fine and never gets in my way.
I have a similar setup to yours now. In fact, I copied and adapted it from that exact file you linked, so thank you! I agree that there are no major issues with this setup. But for my specific use case it does get a little bit inconvenient: * I am trying to write a Lua module that can act as a higher level API for the tex modules and functions exposed by LuaTeX. * This module should be available to install by a standard Lua package management mechanism like LuaRocks * This module (and consumers of this module) should be able to use other Lua modules packaged with LuaRocks as well. All of the above can be achieved by some sort of wrapping. I have a wrapper[1] that currently: 1. Creates a pre-init Lua file to load a package from LuaRocks. This is because, just after that kpse is initialized and the the "require" function starts using a different mechanism to search for packages 2. Creates a stub tex file in the local directory with the same name as the lua file (for e.g. hello.lua -> hello.tex) and writes some stub code with \directlua that calls the preloaded module in step 1 to do some initializations, like augmenting the package loading mechanism[2] to use LuaRocks before using kpse. * Invokes the LuaTeX interpreter (with the --lua flag to call the pre-init file) to call the stub tex file and generates the PDF. It would be really nice to be just able to do something like: > luatex --ini --some-other-flag hello.lua and get a PDF :). Or maybe if we want to keep the functionality in a format: > luatex --fmt=my-custom-format.fmt hello.lua Although that would mean I still need a TEXMF tree somewhere to keep a format file around. Deepak [1]: https://github.com/deepakjois/ufy/blob/master/bin/ufy [2]: https://github.com/deepakjois/ufy/blob/master/src/ufy/init.lua#L4
