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

Reply via email to