References to named labels inconsistent

[Qrrbrbirlbel]

As per section 2.3 of the manual, forest allows to use TikZ' \path commands to draw additional stuff around a tree. The examples of the manual use the nodes of the tree, either implicit or by their author-given name.

However, when labels are named and later referenced, for me, something inconsistent is happening.

Consider the following MWE where Label adds a label to a node and names it and where \Path references the given node-name explicitly via TikZ' node coordinate system. (If we don't use node cs we get loads of errors that don't help.)

\documentclass[tikz]{standalone} \usepackage{forest}
\forestset{Label/.style={label={[font=\tiny,name=#1]left:#1}}}
\newcommand*\Path[1]{\path (node cs: name={#1});}
\begin{document}
\Forest{[0 [A, Label=LA] \Path{LA} ] }% Reference directly after the labeled child -> works
%\Forest{[0 [B, name=nB, Label=LB]  ] \Path{nB}\Path{LB} } % Reference after the tree -> LB: no, nB: yes
\Forest{
    [0 [E [F, Label=LF] ]
       %% Alt 1:
       [] \Path{LF} % works
       %% Alt 2:
       % \Path{LF} % LF not known
    ]
}
\end{document}

The first tree works because LA is referenced directly after the label's parent's closing ]. The second tree can't find LB although it does recognize nB. The references are done after the last ] (similar how section 2.3 uses raw TikZ commands).

In the third tree the line after Alt 1 works, the line after Alt 2 does not.

Alternative 2 is similar to the second tree where the label is referenced far after its node:

\Forest{
    [0 [E [F, Label=LF] \Path{LF} % directly after F (and inside E)
       ]
       \Path{LF} % LF not known, directly after E
    ]
}

Alternative 1 adds a second child besides E and suddenly LF can be referenced.

\Forest{
    [0 [E [F, Label=LF] \Path{LF} % directly after F (and inside E)
       ]
       [] \Path{LF} % works, empty child behind E
    ]
}

Obviously, I don't want to use an extra empty child but I would like to reference the labels preferably after the whole tree and not somewhere inside.

[sasozivanovic]

Sorry for a very late reply.

label works through the tikz option, same as the afterthoughts behind the brackets. This means that however we swing this, the tikz code of some nodes will be executed before the tikz code of other nodes. By default, the nodes are typeset (and their edges draw, and their tikz code drawn), in tree order, which is parent-first. So in your particular case, setting processing order/.nodewalk style=tree children-first solves the issue. (One could also set draw tree tikz processing order in particular.)

I remember considering the following idea at some point: to consider everything behind the final bracket a "postamble" which gets executed after everything else. At the moment, that stuff is the afterthought of the root node, and respects the processing order(s). (Note that one could still add "regular" tikz code to the root node by an explicit tikz.)

I wonder how many documents this would break ...

[cfr42]

I suppose you could use one of the methods which allows referencing non-existing nodes on first compilation and then saves them, but that would mean potentially writing a lot of information just-in-case.