References: <559AE0A8.3080907@morningstar2.co.uk> <55A3E1DD.8050707@posteo.net>
            <55A3E5E6.2060405@morningstar2.co.uk> <55A4137A.7030807@posteo.net>
            <55A415FF.8030305@nag.co.uk> <55A801A8.5090702@posteo.net>
            <55A809C4.70009@nag.co.uk> <55AA1554.3050509@posteo.net>
            <55AA24D9.1050904@latex-project.org> <55AA29B9.9050104@posteo.net>
            <55AA5596.4090007@telecom-bretagne.eu>
            <55AA755E.5000609@posteo.net> <55AB5AF6.2030301@nag.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
            Thunderbird/38.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <55AB7AF0.2070602@posteo.net>
Date:         Sun, 19 Jul 2015 12:24:48 +0200
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Stephan Hennig <sh-list@POSTEO.NET>
Subject: Re: LuaTeX support in the LaTeX kernel
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <55AB5AF6.2030301@nag.co.uk>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

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