@cfr Yes, the idea was to have a "plain" signal for completeness. However, although I haven't written back (other stuff to do) I was thinking about all this ...

@cfr So we were zigzaging between my craziness and craziness of others, and we're aiming for something in between. Now I realized that if I wanted to implement deprecation warnings this would essentially mean my craziness all the way. But once I've done that it makes no sense to share it with others ...

What I'd like to do now is take from our discussion the fact that we have two usage cases: one where a plain number is the default (like y=...) and others where pgfmath is the default (like if={...}). In the default=plain case, I'd make myself crazy and implement a fast-check to see if the user has provided a plain value (an integer or a dimension, depending on the context); if not, I call pgfmath.

In the default=pgfmath case and the case of a default=plain which failed (so essentially, whenever I call pgfmath), I would first check if > is the first character. If yes, this is a signal that our pgfmath expression is in fact a process expression.

In a nutshell, if I managed to implement fast enough is-it-plain-checking, the "regular" user would have no backwards-incompatible-change in syntax at all, the "programmer" could use process wherever pgfmath is allowed (with no extra keys like if' added), and everything would run faster.

I have already taken a stab (with help of info at TeX.SE, of course!) at implementing a fast scan for an integer. While it is ten times slower than a plain TeX assignment, my fast-scan is 2-5 times faster than pgfmath's internal fast-track (depending on the number of digits in the number), in cases where pgfmath's fast track works. For negative numbers, for example, where pgfmath has no fast-track, it's 20x faster, not to mention that pgfmath actually doesn't handle large negative numbers.

@SašoŽivanović ;)

@SašoŽivanović This sounds better. It was something like this I had in mind when I suggested using a signal for the process stuff rather than the pgfmath, but then the plain case seemed to make things that much more complicated.

The current plan seems saner to me in terms of the user interface. (Can't really say about the code!)

@cfr Great! (And I believe the code will be fine, too!)

@SašoŽivanović Excellent! Can you send me a draft when you've got one?

@cfr Definitely!

@SašoŽivanović By the way, somebody is reinventing node walks, I think:

Also, FYI: logicmatters.net/latex-for-logicians/trees and logicmatters.net/2016/04/03/….

@cfr Indeed! If he decides to switch to forest, that will be a very cool application of nodewalks!

@cfr Oh yeah!

@SašoŽivanović He's written up Forest, too. Before the coverage consisted of a comment by me saying 'there's also ...'.

@SašoŽivanović The published version of Forest breaks some code I have, but works with the rc version I've got. What are the chances that if I just wait, I won't have to figure out how to fix it?! This answer, which I just posted, turns out to depend on the RC version. And so do my examples using justtrees. Which is weird because I've hardly done anything to justtrees and it worked fine with 2.0.2. I fixed one bug which neither the CTAN version...

nor the rc version liked. (Neither tolerate a dimension without units, even though TikZ is happy to use 0 rather than 0pt.) But there's something else which breaks with the CTAN version even though it worked with 2.0.2 and works again with the rc. But I can't figure out what.

@cfr Ayy. I'm sending you my latest code, can you check the situation? ---This is for the bugfix release (2.0.3), not 2.1.0 where I will address performance issues. That one will take more time than I have thought.

@cfr I've just finished preparing the 2.0.3 release this evening, when my computer died. :-( Bye bye fan on the graphics card. So, as I don't have the testing suite on my laptop, I cannot release today. But maybe good that I haven't, if this turns out to be yet another bug, maybe it can be fixed.

@cfr Have you been setting names of nodes programmatically? There might have been some changes in that area, wrt node name uniqueness. Something I've fixed and is in the file I have just sent you.

@SašoŽivanović I think this fixes it. That is, I now get a different error but I think that's my fault. I think I'm muddling what's not there with .process args so it won't work. But I'm not getting errors about node ids, which were probably related to the bug you said this fixes. (If that makes any kind of sense.)

@cfr Makes. Good. Glad.

@SašoŽivanović Yes. My test file builds OK with the 0 -> 0pt change in the sty if I remove the latest addition to the examples. Now I need to figure out a pgfmath version.

@cfr How was this 0 used?

@SašoŽivanović I had something like declare dimen={whatever}{0} which doesn't work any longer. Changing it to 0pt fixes it.

@cfr Yes, this is expected :-)

But not welcome. I will fix declare count etc to parse the default value using pgfmath.

@cfr Sent. Please test!

@SašoŽivanović Changing to 0pt was really pretty painless: the error message was meaningful and it was easy to identify the issue. It was the errors about forest node ids which I couldn't figure out. But those are already fixed in rc5.

@cfr I know, but still. It has worked before, it should work now!

@SašoŽivanović But you will have to parse every declaration of a dimension/count option/register with pgfmath. That seems a waste.

@cfr (a) Compared to everything the package does, that's not a lot of evaluations. There declarations never appear in loops, for example. (b) I'm having the eye to the future, where this actually won't be parsed by pgfmath, because this will be one of the "simple" cases.

(c) Not doing it would break some existing code. And I don't like doing that ... even if sometimes I must.

Hi @SašoŽivanović and @cfr, can I ask you both a quick question that I should probably know the answer to but don't. :p How do I change the line thickness of the branches in a forest tree?

@AdamLiter for tree={edge={line width=4pt}} ?

@SašoŽivanović

content/.wrap 2 pgfmath args={\frac{#1n}{#2}}{(tree_n()==1) ? "" : (tree_n())}{int(3^(level("!u")))},
%               content/.process args={Ow1+POw1+Pw2}{tree n}{#1==1 ? "" : #1 }{!u.level}{int(3^#1)}{\frac{#1n}{#2}},

The first is horrible. The second is going to be wrong, but it was easier to write.

Even when it does need pgfmath.

@cfr Thanks! :) Fast as ever.

@AdamLiter Untested ;).

@cfr It does result in uneven meeting of branches. No idea if you have a quick fix for that. If not, don't worry about it. :p

@SašoŽivanović Can't decide what to do with justtrees.sty. I keep answering questions with it because it seems to come up so frequently, but it isn't really a proper package.

@AdamLiter Damn. I want to think about this.

@AdamLiter I know. I don't have a fix, either. I know I've tried things but they haven't worked. The problem is that you are looking at two distinct paths. Changing the line cap to something else might help. Do you have code?

@cfr Yes, but I don't want to bother you with this. :p There's a time crunch. This is for a poster for some undergraduate research that is being presented in a couple of days.

And it should probably be printed today, so that they can practice presenting the poster. :p

But yeah, we need thick lines so that things are visible on a 32in x 40in poster. :p

I think we can live with this aesthetic problem for the moment. :)

The issue is there anyway. It is just less obvious:

\documentclass[tikz,border=10pt,multi]{standalone}
\usepackage{forest}
\begin{document}
\begin{forest}
  for tree={parent anchor=children}
  [VP
    []
    []
  ]
\end{forest}
\end{document}

@cfr Ah, yeah, good point. I've never actually noticed that. :p

@AdamLiter Is this better?

\documentclass[tikz,border=10pt,multi]{standalone}
\usepackage{forest}
\usetikzlibrary{arrows.meta}
\begin{document}
\begin{forest}
  for tree={
    parent anchor=children,
    edge={line width=4pt, line cap=round, -Butt Cap},
  }
  [VP
    []
    []
  ]
\end{forest}
\end{document}

Note that it doesn't work with Round Cap- and I don't know how to do the equivalent of line cap=round for only one end. Hence the override with -Butt Cap.

@AdamLiter Quick and dirty.

\documentclass{article}

\usepackage[linguistics]{forest}

\forestset{
  nicely joined edges under/.style={% only for binary nodes!!!
    for 2={no edge},
    for 1={edge path'={%
        (.child anchor)--(!u.parent anchor)--(!u2.child anchor);
      }}
  }
}

\begin{document}
\begin{forest}
  for tree={edge={line width=4pt}},
  where n children=0{}{nicely joined edges under},
  [VP[DP][V'[V][DP]]]
\end{forest}
\end{document}

Thanks to you both! @SašoŽivanović, I think @cfr's solution might be better in our case because we're committing the blasphemy ( :p ) of having a ternary branching node in this case ...

@AdamLiter That can be remedied actually, but I believe rounded caps will look nicer indeed.

@AdamLiter Do you have any only children? If so, you need to override the change or you'll have a round end at the top and a butt end at the bottom.

Anyways: proof of concept: one path for several edges.

@cfr Yep, thanks!

\documentclass[tikz,border=10pt,multi]{standalone}
\usepackage{forest}
\usetikzlibrary{arrows.meta}
\begin{document}
\begin{forest}
  for tree={
    parent anchor=children,
  },
  where level=0{}{%
    if={n_children("!u")==1}{edge={line width=4pt}}{edge={line width=4pt, line cap=round, -Butt Cap}},
  }
  [VP
    [[]]
    [[][][]]
  ]
\end{forest}
\end{document}

@AdamLiter ^^

Thanks @cfr! Thanks again to both of you!! I really appreciate it. :)

@AdamLiter You're welcome. Actally, many thanks for pointing this out. The problem is actually more general: in some cases (forked edges etc), one would prefer drawing the edges of all children simultaneously. Thinking of a general approach now ...

@cfr Well, but it does work.

@SašoŽivanović Yes, the first works. I agree. And that is surely an advantage ;).

@SašoŽivanović Fortuitous timing that there's an undergraduate research conference coming up at our university then ... :) Anyway, I need to go back to helping get the posters and the undergraduates ready. Talk to you both later! :)

@cfr They both work!

@AdamLiter Good luck with that!

@SašoŽivanović The second works with 2.1 rc1 but it won't work with 2.1 ;).

@AdamLiter Enjoy!

@cfr Ahh that's true ...