Am 19.07.2015 um 10:08 schrieb David Carlisle: > On 18/07/2015 16:48, Stephan Hennig wrote: >> What's needed is a defined programming API. >> With two implementations (luatexbase and ltlatex) that is more or less >> already there. > > > So is there anything in the current ltluatex that you object to? > It would appear not. The ltluatex code implements the existing > luatexbase API sufficiently well that many (all?) existing packages > including spelling work unchanged (see pkgtest on github) and also > works from plain tex as well as latex (see plaintest). Sorry, I haven't kept-up with ltlatex since a884. Nothing to object at that time. Regarding my two feature requests: 1. The first one is against the current luatexbase package and irrelevant for ltlatex, I think. You can't currently write a /self-contained/ Lua module that requires, e.g., the mcb.lua module. As soon as luatexbase or luatexbase-mcb are already loaded at the TeX level, callback registering breaks. \begin{filecontents*}{self-contained.lua} if not (luatexbase and luatexbase.require_module) then require('modutils') end luatexbase.require_module('mcb') luatexbase.add_to_callback('pre_linebreak_filter', function (head) return head-- do nothing end, 'foo') \end{filecontents*} \documentclass{article} % Loading the luatexbase or luatexbase-mcb package % at the LaTeX level breaks callback registering. %\usepackage{luatexbase} \directlua{ dofile('self-contained.lua') } \begin{document} text \end{document} Of course, one can work-around that by testing for features before requiring mcb.lua, but placing the guard in mcb.lua would be nice. 2. When registering a callback, there's no way to know what happens before or after your code /in the same callback/. That is, the list you're dealing with may already have been modified or may be subject to further modification in the same callback. For debugging purposes, it's sometimes desirable to see the original list passed to or returned from a callback. Package luatexbase already provides a priority system, but that doesn't help much, because you can't rely on staying at the requested priority. Speaking about debugging, that is, printing or drawing a node list, these operations are usually non-invasive, i.e., they don't modify a node list. The callbacks provided by LuaTeX could be wrapped in two additional callbacks, each. A function registering any of the proposed new callbacks gets a copy of the original list as argument so that it cannot modify the original list. That way, one can be sure to see what's originally passed to or returned from a callback. It's easy to model this around a basic format-dependant callback allocation implementation. So this is more of an idea than a request for a kernel implementation (that a Lua package author targeting multiple formats won't use directly). Best regards, Stephan Hennig