# [Dev-luatex] next steps in development

Hans Hagen pragma at wxs.nl
Sun May 7 20:25:52 CEST 2006

Taco Hoekwater wrote:
> Hi,
>
> Hans Hagen wrote:
>>
>>
>> goal: starts an lua instance
>
> Expect the primitive syntax to be more like the internals of \toksdef,
> so the toplevel user command would be \newlua.
>
> There is a catch though: I want to reserve one number for internal
> use (callback functions that handle C functionality, like finding
> files). Maybe 255, since Tex uses 255 for various things anyway.
> WDYT?
ok, although we get an insert like \new* then, so how about just
starting at zero and then advice (given a luadef); also, we've run out
of alloc  counters, so we may as well implement newlua different anyway

\newlua \luacallback
\newlua \lua

i.e.

anyhow, since we cannot use \alloc@ , the 255 is also ok

\newcount\@@luainstances

\def\newlua#1%

if we compare to boxes, counts etc, there is not something like \lua0 to
use as scratch lua instance unless we also can reset such an engine
which we need anyway (btw, lua instances are grouping transparent)

we can have a \luadispose (or do a redef) but then we alse need to be
able to check if an \cs is representing a lua etc etc although we may
assume sane usage

\def\newlua#1%
\ifnum\@@luainstances=254 2\else 1\fi \fi

ok:

\newlua \temp % new instance
\newlua \temp % kill existing and create instance
\newlua \temp % kill existing and create instance

while:

\newdimen \temp

\newlua \temp % fails unless  we have an \iflua\cs as in:

\def\newlua#1%
\ifnum\@@luainstances=254 2\else 1\fi \fi

\def \temp {whatever}

\newlua \temp % fails unless  we have an \iflua\cs as in:

of course this overload can also happen with registers but then we only
loose some mem, while with lua we get pending engine *using up much mem)

>
>> (3) \immediate\luacs
>>
>> goal: feeds back into the token scanner (no need for scantokens,
>> faster due to less parameter passing)
>> usage: \immediate\lua{tex.print("$x$")}
>
> This could be the normal behaviour of tex.print(), and if you do
> not want it, you could run \detokenize yourself. And we could have
> a separate function tex.write() for detokenized use.

I opt for two functions (no messing around with detokenization)
>
>> further, taco and i discussed a lua extension using a variant of
>> strings using 32 bit entries, partly for the unicode chars and partly
>> for the \cs etc pointers so that we can do stringlike thinsg with
>> token lists
>
>
>> well, we discussed more, but i need to search my memory -)
>
> Amongst other things, we also talked about a new way to load
> and use fonts:  not letting TeX read .tfm and .vf files, but
> using a ruby library for the internal font loading. That library
> then has to return a table with a specified set of keys.
> That way, we could have reencoded and synthetic (virtual) fonts
> from all over the place without being tied to compiled code or
> font formats.
indeed; same for map files

Hans

-----------------------------------------------------------------