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 P.Jackowski@gust.org.pl