[Dev-luatex] order of node linking matters

Paweł Jackowski P.Jackowski at gust.org.pl
Wed Dec 23 18:29:35 CET 2009


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 at gust.org.pl


More information about the dev-luatex mailing list