Hello,
The issue I had was trying to find a nice solution for
tex.count[0] = 5
Now I just realized (this morning) that I could create a second virtual array named
tex.globalcount[0] = 5
or some such.
Maybe tex.count.local[0] and tex.count.global[0]?
Your
tex.setcount (0,5,true)
proposal is fine, but the array access is so neat that I would like to keep it.
I agree.
I would try my hand at a patch to implement this, but unfortunately, I cannot find the function prototype for set_tex_count_register. A
It is in luatex.web, just below get_tex_count_register.
But that is the implementation. I meant the function prototype used by the C code to know how the WEB function is called (parameter types etc.).
Your web implementation proposal sounds fine, but before we do anything about extending the lua syntax, we have to think about those array accesses and the other tex internals, I think.
The interface to the tex internals is still incomplete, and that is mostly because of syntax issues. It is fun that we can write
tex.globalsdefs = 1
as an assignment instead of as a function call, and
tex.count[0] = 5
as well, but many internal parameters are not interfaced yet because they are not so simple. The tricky bit is that I fear that some of the internals really require a functioncall instead of assignment, for example \parshape and \fontdimen.
Maybe tex.parshape = { { "0pt", "30pt" }, { "10pt", "20pt" } } This would result in \parshape=2 0pt 30pt 10pt 20pt Read access would return 2 (the number of lines). Of course, this would require temporary tables, so an alternative syntax might indeed be a function call (the number of lines is calculated from the number of parameters): tex.parshape("0pt", "30pt", "10pt", "20pt") Maybe there is a way to implement both syntaxes, although I'm currently pessimistic: tex:__index("parshape") could return a function which sets \parshape (leaving tex:__newindex("parshape", ...) to perform the table assignment), but then read access would also return this function, not the number of lines. Maybe it would be better to use tex.setparshape for the function call. fontdimen could be a two-dimensional array, with the first dimension being the font and the second the dimension to set: fontdimen[1][1] = 0 fontdimen[2] = { 0, 1, 2, 3 } Access to TeX's control sequences might be difficult without functions, though. OTOH: tex.cs.from = { "#1 to #2", "From #1 to #2" } being equivalent to \def\from#1 to #2{From #1 to #2} The first element of the array could be an optional bitfield to specify \long, \outer etc: tex.cs.from = { 1 + 2, "#1 to #2", "From #1 to #2" } i.e. being equivalent to (1 = \long, 2 = \protected) \long\protected\def\from#1 to #2{From #1 to #2} Now, catcode tables ... maybe: tex.cs.from = { 1 + 2, "#1 to #2", { 1, "From #1 to #2" } } Still, this would be a nightmare to use. Maybe use factory functions: tex.cs.from = tex.macro.new("#1 to #2", "From #1 to #2") tex.cs.from = tex.macro.newL("#1 to #2", "From #1 to #2") ... tex.cs.from = tex.macro.newLP("#1 to #2", "From #1 to #2", 1) The latter would create a \long \protected macro using catcode table 1. This scheme would require 8 new variations for \long, \protected and \outer (\global is a matter of assignment and should be handled by the tex.cs-table the macro is assigned to). Or: tex.cs.from = tex.new.macro... tex.cs.from = tex.new.macroL... ... This could be extended to: tex.parshape = tex.new.parshape(...) While we're at it: Maybe dimensions and glue could get their own data type (implemented as a user data object), so that calculations etc. are easier to perform in Lua: local d = dimen.new(12, "pt") -- 12pt local g1 = glue.new(12, "pt") -- 12pt plus 0pt minus 0pt local g2 = glue.new(12, "fill", "pt") -- 12pt plus 1fill minus 0pt local g3 = glue.new(12, "2fill", 10, "pt") -- 12pt plus 2fill minus 10pt
Best wishes, Taco
Jonathan