Make the late_lua node accessible from the executed code
Hi, one issue I regularly encounter with late_lua whatits is that they don't allow the executed code to determine which node is currently executed. Especially this means that attributes and properties can't be reliably accessed and the code can't access related nodes next to the late_lua node. This can be worked around by storing a closure in the data field which captures a reference to the node, but this breaks in hard to debug ways when the node is copied and the copied node has the same code but a different identify. Therefore it would be great if there would be a way to access the currently evaluated late_lua whatsit node. I would have suggested passing this as an argument to the executed function, but that could break compatbility and it would appear odd due to LuaMetaTeX using the second argument of lua functions is different ways. So the attached suggested implemention instead adds a separate function which allows to access this node: node.current_latelua (or node.direct.current_latelua) Best, Marcel
On Mon, Feb 28, 2022 at 1:02 PM Marcel Fabian Krüger
Hi,
one issue I regularly encounter with late_lua whatits is that they don't allow the executed code to determine which node is currently executed.
Especially this means that attributes and properties can't be reliably accessed and the code can't access related nodes next to the late_lua node. This can be worked around by storing a closure in the data field which captures a reference to the node, but this breaks in hard to debug ways when the node is copied and the copied node has the same code but a different identify.
Therefore it would be great if there would be a way to access the currently evaluated late_lua whatsit node. I would have suggested passing this as an argument to the executed function, but that could break compatbility and it would appear odd due to LuaMetaTeX using the second argument of lua functions is different ways. So the attached suggested implemention instead adds a separate function which allows to access this node: node.current_latelua (or node.direct.current_latelua)
Hans has made a patch, see revision 7504. -- luigi
On Mon, Feb 28, 2022 at 08:15:41PM +0100, luigi scarso wrote:
On Mon, Feb 28, 2022 at 1:02 PM Marcel Fabian Krüger
wrote: Hi,
one issue I regularly encounter with late_lua whatits is that they don't allow the executed code to determine which node is currently executed.
Especially this means that attributes and properties can't be reliably accessed and the code can't access related nodes next to the late_lua node. This can be worked around by storing a closure in the data field which captures a reference to the node, but this breaks in hard to debug ways when the node is copied and the copied node has the same code but a different identify.
Therefore it would be great if there would be a way to access the currently evaluated late_lua whatsit node. I would have suggested passing this as an argument to the executed function, but that could break compatbility and it would appear odd due to LuaMetaTeX using the second argument of lua functions is different ways. So the attached suggested implemention instead adds a separate function which allows to access this node: node.current_latelua (or node.direct.current_latelua)
Hans has made a patch, see revision 7504.
Thank you, that works great for all my usual usecases. One remark: It explicitly excludes the case if `lateluafunction`. Now I never needed that in \lateluafunction, but that's mostly since I barely ever use that one. Since it requires a pre declared function my primary issue with it always was that it can't be adapted to a specific situation at all. I think that this change and especially the ability to access properties could have made \lateluafunction significantly more useful since it would have added the option to have limited levels of customization combined with the generally great behavior with otherwise static predeclared functions. So I think it would be nice if you could consider extending this in some way to work there too. Best, Marcel
-- luigi
_______________________________________________ dev-luatex mailing list dev-luatex@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-luatex
participants (2)
-
luigi scarso
-
Marcel Fabian Krüger