dangling prev fields?

[lemzwerg]

Consider this input

\input nodetree.tex
\NodetreeSetOption[verbosity]{3}

\NodetreeRegisterCallback{preline}

office

\bye

which produces the following output (using #11).

I now wonder what is going on with the prev fields that point to elements not shown here, for example prev: 312. Does element 312 no longer exist? Is this prev field invalid? Is this a bug because the prev fields haven't been unset properly? I guess it makes sense for the former cases – in case this can be detected (which I really hope) – to write, say, prev: 312 (unreachable).

[Josef-Friedrich]

I must admit that I have not yet thought about the prev field.

From the LuaTeX reference manual (Page 127)

Besides these three fields, almost all nodes also have an attr field, and there is a also a field
called prev. That last field is always present, but only initialized on explicit request: when the
function node.slide() is called, it will set up the prev fields to be a backwards pointer in the
argument node list. By now most of TEX’s node processing makes sure that the prev nodes are
valid but there can be exceptions, especially when the internal magic uses a leading temp nodes
to temporarily store a state.

[lemzwerg]

Ah, ok. Not sure whether it would make sense to track next nodes so that the value of prev nodes could be checked and marked as 'uninitialized' if it doesn't point to a reachable node.

[Josef-Friedrich]

I tried using the function node.is_node(node.prev) to check if the prev nodes are valid. All nodes displayed via the command line output were valid.

[lemzwerg]

Ok, they are valid – but how to use nodes that don't appear in the listings? The obviously point to something that shouldn't be considered in a given callback. Or am I missing something?