@cfr I just finished work on improving .process args, so that it also does wrapping. It can be used instead of .wrap pgfmath arg(s)in cases when you don't really need pgfmath: much faster, and actually also simpler to use, in my opinion.
I'm testing with both our examples and manuals (I hope you don't mind). prooftrees-egs gets about 15% boost in speed. But your manual still has to compile ;-(
@cfr You wish. If it's anything like in mine, it's the trees. I compile both with and without externalization, and the difference is huge, though the code still gets typeset. ---I plan to switch to tcolorbox listings some day in the future as well ... too bad I didn't know about it when I started ...
@cfr True. ;-) Anyways, having your package available for testing my development really helps a lot.
@SašoŽivanović It will definitely break if you do that. There's non-Forest stuff in there which doesn't work with externalisation. If I could externalise the Forest trees, I'd have to switch it off for the problematic cases. This is what I usually do, actually, except I switch it off automatically for all Forest environments because I could never get it to work.
@SašoŽivanović Forest is just one thing which doesn't work with externalisation. Anything using tikzmark fails because it needs multiple compilations to get the placement right. And some of the fancier tcolorboxes fail if externalised, though the more basic ones work OK. For the manual, it would make a big difference just because there are lots of trees. But in other documents, I can mostly use externalisation. The biggest issue is with Beamer. If I incrementally uncover a tree, it needs forever.
In a forest environment you can use TeX={\color{blue}} if you don't mind the entire tree turning blue, of course. But it does colour the turnstile. Which I guess makes sense.
Ok, let me write more details. \tikz{\node [text=blue] {$p \leftrightarrow q \sststile{}{} p \rightarrow q$}; } produces the same thing as forest. So I think we can take forest out of the picture. (Though I'd like to know why it behaves like "plain TikZ" [text=blue] when we write blue.)
@SašoŽivanović I definitely agree this is basically a TikZ/turnstile issue. I didn't know whether Forest's doing something different would provide any clue to what the underlying issue is. I wonder why about the blue/text=blue, too. But you could ask why blue` doesn't do what text=blue does in TikZ. I'd assumed initially I would reproduce this outside TikZ, but there it works.
@cfr Ok, I've managed to reproduce the error without turnstile. The problem are saveboxes: \newsavebox{\myfirst}\tikz{\node[blue]{$p\sbox{\myfirst}{$x$}\usebox{\myfirst}q$};}. I guess tex.stackexchange.com/q/247849/16819 is relevant here.
@cfr And without tikz: {\color{blue} blabla \sbox{\mybox}{$x$} \settoheight{\lengthvar}{\usebox{\mybox}} \usebox{\mybox} tralala}.
The start of the explanation for text=blue / blue might be that they apply color at slightly different times.
@SašoŽivanović Thank you! Let me check I understand: TikZ is expanding the turnstile command of the \sbox before is applies blue to the node's contents. Is that right? And in the case of text=blue it somehow applies the colour differently so that the colour of the saved box contents leaks onto everything that follows ?
