Message-ID: <55955C00.6080000@morningstar2.co.uk>
Date: Thu, 02 Jul 2015 16:42:56 +0100
From: Joseph Wright <joseph.wright@morningstar2.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: =?windows-1252?Q?=C9lie_Roux?= <elie.roux@telecom-bretagne.eu>,
        heiko.oberdiek@googlemail.com, mpg@elzevir.fr,
        Philipp Maximilian Stephani <p.stephani2@gmail.com>,
        Philipp Gesang <Philipp.Gesang@alumni.uni-heidelberg.de>
Subject: Re: LuaTeX support in the LaTeX kernel
References: <559534D0.2060001@morningstar2.co.uk>
 <5595540F.9080605@telecom-bretagne.eu>
In-Reply-To: <5595540F.9080605@telecom-bretagne.eu>
Cc: "latex-team@latex-project.org" <latex-team@latex-project.org>,
        Lars Madsen <daleif@imf.au.dk>
Precedence: list
Content-Type: text/plain; charset="windows-1252"
Errors-To: latex-team-bounces@latex-project.org
Sender: "Latex-team" <latex-team-bounces@latex-project.org>
Content-Transfer-Encoding: 8bit
Status: R

On 02/07/2015 16:09, Élie Roux wrote:
> CCing Philipp Gesang, who is an important author of luatexbase and
> luaotfload.

I couldn't find an address for him from e.g. packages, GitHub hence the
omission.

>> *Catcode allocation*
>>
>> We have just covered the core idea of allocation. In contrast to 
>> luatex/luatexbase we have gone for a simple allocator as for other 
>> registers. We think that a stack mechanism belongs at the package
>> level (catcode tables seem more useful from Lua than from TeX in any
>> case). David has sketched out a pool-based approach to a stack in the
>> attached catcodestack document.
>>
>> We have not at this stage pre-defined any tables. We suspect a core
>> set (IniTeX/string/document) may well be useful: thoughts welcome.
> 
> This would be helpful indeed, or most package using catcodetables will
> define their document, string and makeatother tables...

As I see David has also noted, the current doc level one is wrong as it
ignores the Unicode full range :-) I wonder about the usefulness of
'code level' tables: really Lua code should not be returning
\@firstofone or whatever but rather document-level text, no?


>> *Callbacks*
>>
>> We have significantly minimised the callback allocator from
>> luatexbase to cover just the idea of registering multiple callbacks
>> but not resetting/removing/...
> 
> I think removing a callback is quite useful: for instance in Gregorio
> (https://github.com/gregorio-project/gregorio, soon to be integrated
> into TeXLive) I make quite convoluted treatment in postlinebreak_filter,
> but only in the context of a score, so I register the callback at the
> beginning of a score and remove it at the end.. Well, I could find other
> means to check if I need to run the callback or not, but I admit I liked
> this way of using callbacks.

I guess I was imagining that callbacks should turn themselves on or off
depending on context rather than being installed/uninstalled on the fly.
Not knowing a lot about the use cases I may have missed something.

>> We have kept a public interface to the built-in callback.register 
>> function with the idea being that a more sophisticated package
>> interface could be introduced and replace the kernel version.
> 
> That seems like a terrible idea: some packages would register callbacks
> in the LaTeX core interface, and if another registers a callback in the
> more sophisticated interface, the first callback will be overwritten...
> Maybe a solution to this and the removal could be to make the callback
> function lists public?

Should have been clear that it also occurred to me we'd need a public
interface to the LaTeX kernel list and clear instructions that any
augmented version must pick this up and continue to provide the basic
interface too. Remember I'm a TeX programmer so I'd just \let stuff
whether it was 'private' or not :-)

> Why not include the code adding kpse to package.searchers ? Or would it
> be better to add it when building the format (so that LaTeX doesn't
> depend on kpse)?

I thought nowadays LuaTeX handled this sort of thing without active
intervention, or do I miss something.

> Why not include a whatsit allocator (like the one in
> https://github.com/lualatex/luatexbase/blob/master/luatexbase-attr.dtx#L484)?
> This was a request from users and could have its place alongside the
> other allocators.

It all seemed a bit esoteric to me, and the lack of a TeX primitive to
use it suggested it was not that useful. I am happy to be shown to be wrong.

Joseph


_______________________________________________
Latex-team mailing list
Latex-team@latex-project.org
https://lists.dante.de/mailman/listinfo/latex-team