LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Subject:
From:
Joseph Wright <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Mon, 13 Jul 2015 18:10:20 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (69 lines)
On 13/07/2015 17:23, Joseph Wright wrote:
> On 13/07/2015 17:05, Stephan Hennig wrote:
>> Am 06.07.2015 um 22:10 schrieb Joseph Wright:
>>
>>> We are looking for feedback in two areas. Firstly, does the
>>> functionality provided cover the needs of package authors using LuaTeX?
>>> Secondly, we would like input on how a transition to new support code
>>> can be managed. We are reluctant to suggest a complex compatibility
>>> layer for either our code or the existing packages, and suspect at this
>>> stage that a clean 'step change' may be needed for packages working with
>>> LuaTeX. However, this is a complex area and needs careful consideration.
>>
>> Let me question the idea of implementing resource allocation stuff in
>> the LaTeX kernel.  What is the appropriate way to claim resources, e.g.,
>> attributes, in a format agnostic pure Lua low-level module foo.lua
>> (which is then used in format specific wrappers/packages)?  That foo.lua
>> module can't certainly make use of function latex.new_attribute, since
>> that is only available to LaTeX users.  Or do I miss something?
>>
>> Best regards,
>> Stephan Hennig
> 
> We are not unmindful of the problem of code that works with multiple
> formats! Most obviously, luaoftload is required for using the
> higher-level fontspec interface in LaTeX but also works with plain
> LuaTeX to extend the font loader. Whilst we want to work to improve the
> LaTeX support in this area we certainly don't want to break working with
> plain.
> 
> The luatebase package is loaded with plain TeX and is the common way to
> allocate resources. There are a variety of possible approaches where we
> either make it 'aware' of kernel changes or provide a new format-neutral
> package which incorporates the proposed kernel code when used with
> plain. There are also other possibilities and we are considering them.
> 
> Notably, the base registers are all allocated by the routines in the
> formats (plain naming inherited by LaTeX and ConTeXt). The e-TeX format
> continued that tradition with \newmarks, which we've recently added to
> the LaTeX kernel, whilst \newXeTeXintercharclass has been in both the
> plain and LaTeX format files for XeTeX for some time.
> 
> The key point we are looking at is that allocators really have to be
> loaded very early, ideally as part of a format. We think that LaTeX
> should address this problem but are not going to rush anything. First we
> are learning what support is needed (see ongoing checkins to
> http://github.com/josephwright/ltluatex) and then building on that to
> examine how such support changes can work with existing code.
> 
> Not a proposed solution, but at least worth remembering, in Lua one
> normally allocates local names for functions. Thus for testing at least
> one can do
> 
>     new_attribute = latex.new_attribute or luatexbase.new_attribute
> 
> or similar. We are doing that ourselves to explore what we have or have
> not broken or must consider: see for example
> https://github.com/josephwright/ltluatex/blob/master/doctest.tex where
> David has done a minimal set of 'fix ups'.
> --
> Joseph Wright

To be clear, at this stage nothing is decided, up to and including
whether any of this is ever added to the kernel (though I hope that
something will come of it). The code is quite deliberately not in the
team SVN but is separate so we can make sure that any changes are
workable before altering the core codebase.
--
Joseph Wright

ATOM RSS1 RSS2