Taco Hoekwater wrote:
Paweł Jackowski wrote:
someglyph.next = someother
discretionary.pre = someglyph
is not the same. Why?
Hans:
indeed strange ... a quick hack is to use node.copy on b
Copying the node works in that case, thanks.
Taco:
Because a discretionary's pre, post, and replace lists are a bit
special: internally the discretionary does not just have a next and
a prev link for each of the head nodes, but also a 'tail' link.
That last one points to the last node in the list for each of
the three fields. That extra link is used during hyphenation and
at end-of-line situations (those parts of the code would be much
more complex == slower without it).
Agh, having the disc.tail link(s) at lua level would simplify processing
discretionaries a lot! Why you decided not to interface tails?
So, when in lua you assign to <disc>.pre, that assingment also has
to fix up that tail link (it does so by running the C equivalent
of the node.tail() function).
If the list you are assigning is well-formed, this is transparent.
But yours isn't yet at that point in the code, because 'b.next' still
points to 'd' at the moment the 'd.pre = b' is seen; and that confuses
the internal code into an assertion failure.
Clear.
I admit this is obscure, but the general rule is simple: never
assign a list to a node field until you are sure its internal link
structure is correct. (a warning to this effect will be added to
the manual).
Sounds neat.
I also noticed that assigning disc sublists introduces nested_list nodes:
someglyph.prev = nil
disc.pre = someglyph
assert(someglyph.prev.id==node.id"nested_list")
Is this related here? Is the user supposed to take care about
nested_list nodes (to create them, to destroy them)?
--
Pawe/l Jackowski
[email protected]
_______________________________________________
dev-luatex mailing list
[email protected]
http://www.ntg.nl/mailman/listinfo/dev-luatex