LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mailing list for the LaTeX3 project <[log in to unmask]>
Sun, 19 Jul 2015 12:24:48 +0200
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain; charset=us-ascii
Stephan Hennig <[log in to unmask]>
text/plain (75 lines)
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.

  if not (luatexbase and luatexbase.require_module) then
    function (head)
      return head-- do nothing
% Loading the luatexbase or luatexbase-mcb package
% at the LaTeX level breaks callback registering.

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