3:38 AM
\documentclass[tikz,border=10pt,multi]{standalone} \usepackage{forest} \begin{document} \forestset{% move by/.style={% delay={% replace by={% [xxx, child anchor=parent, parent anchor=parent, append ] }, }, } } \begin{forest} for tree={% plain content, edge path'={(!u.parent anchor) -- ++(0,-10pt) -| (.child anchor)}, }, [Either Alice saw nobody or she didn't see nobody. [Alice saw nobody. ] [Alice didn't see nobody., move by=1
I can more-or-less see why this happens for just the same reason that if you say for tree={red}, nodes added dynamically won't be red.
Is there a safe way to capture relevant options from the preamble so that they can also be applied to dynamically added nodes? I don't want to apply everything from forest's preamble (which includes
proof tree
). I wouldn't hurt if I reapplied user options which configure the style, although it isn't necessary, but I'm not sure what I should or could do about things like edge
and edge path
. especially those. (The nodes I'm concerned with don't actually have any content - no xxx.)
4:00 AM
@cfr This is what I wanted to suggest. But to pick it up automaticall ... I don't see how, especially as it would need to strip
for tree
as well. Hmm, thinking ...
One idea might be to say
process keylist register=preamble
within the new node's options. But this way, for tree={...}
gets executed, so options of the descendants of the new node would be set as well, again. While this causes nothing really bad in this case, it might hurt in general.
This would work. We modify the preamble text using
xstring
package, replacing the first (and only first) occurence of for tree
in the preamble by for current
.
\usepackage{xstring} \fullexpandarg \begin{document} \forestset{% move by/.style={% delay={% replace by={% [xxx, child anchor=parent, parent anchor=parent, TeX={% \StrSubstitute[1]{\forestregister{preamble}}{for tree}{for current}[\temp]% \expandafter\forestset\expandafter{\temp}% }, append ] }, }, } }
8 hours later…
12:35 PM
@SašoŽivanović Hmmm.... thanks. Autoforward sounded really promising, but it seems not in this case. I'd rather not introduce
xstring
if I can avoid it and I'm not quite sure what I'm getting myself into. What if I said
\forestset{% move by/.style={% delay={% replace by={% [xxx, child anchor=parent, parent anchor=parent, edge path/.wrap pgfmath arg={##1}{edge_path("!r")}, append ] }, }, } }
I'm not sure this will work in my real style, but the root node there is added directly in the environment definition, so this would only go wrong - I think - if the user says
for root={edge path=...
or whatever. Which is certainly possible but would be slightly weird. (I can't imagine why you'd do that if using the package for its intended purpose.)
1 hour later…
1:50 PM
And by exposing / documenting the last node in the interface, we could even avoid the potential problems that you're mentioning.
2:04 PM
@cfr A question for you. I'm thinking about namespaces and how to invoke them. An additional optional argument to the forest environment/command seems the way to go. But now, I'm afraid to clutter that interface. I've already got
(stages)
. Then if I introduce maybe <namespace>
, and I'm also thinking of parser
with god knows which kind of delimiters ... it would be a mess, right?
3:04 PM
@SašoŽivanović This sounds perfect. After I wrote the above, I thought that it would make more sense to use
!1
than !r
so that if the user changed edge
or edge path
for the node, it would get picked up. But then, of course, I need at least another cycle to ensure the node is append
ed to the replace by
. It sounds as if forest@last@node
would handle all this. If I've understood correctly.
@SašoŽivanović Why parentheses rather than square brackets? Why not
[stages={}, namespace={},...]
? Would this work with \forest... \endforest
?
Judging by questions here, I doubt that people are making extensive use of v2 features yet, but it is hard to be sure of that, naturally.
Also, it is a relatively easy thing to change with a regex. So long as the effect is exactly the same. I also think that the
[(...)]
syntax is potentially confusing because so non-standard. And a key-value interface is much more intuitive in this context.
I think the benefits of the new syntax would outweigh the potential harms. 2 months is not that long. And, let's face it, the only people who might be using it will be people who've read the documentation and got to grips with the new features. That's going to be a fairly small proportion of your total user base.
By the way, when I read the manual, I expect the syntax of
\Forest
to accept a star in square brackets rather than a simple star. I think it would be much clearer to list both forms one right above the other.
@SašoŽivanović I just realised there are probably no square brackets here at all.... You are just using them to indicate the arguments are optional? I think round brackets are fine given that you really can't have square here. But it is very, very confusing to use square brackets in the syntax specification in the manual when those brackets should not be actually entered. People expect that syntax to mean an optional argument of the
[<>]
kind....
3:51 PM
I see that we share the opinion, both pro and contra arguments. I'll try to post a new version this weekend.
@SašoŽivanović Er... well, I'm actually marking all created nodes within the main proof tree so that I can avoid including them when doing certain things to the tree as a whole. I exclude the line numbers and justifications because they are marked as line numbers or justifications. But that's pretty straightforward. I don't know if that feature would make it easier. For me, right now, probably not because I've yet to experiment with saving/loading node walks. But might somebody familiar with...
@SašoŽivanović I think it would be useful, although I would not want to use it in this case. My dynamically created nodes all need different properties from regular nodes and I'm to some extent relying on the fact that they don't inherit options standardly. (Where they do, I undo it.) But they also don't all have the same different properties.
So I have justifications which get one set of options, line numbers, which get another and two kinds of created nodes in the main tree. One needs
l=0pt
and gets aligned over its parent node and essentially ends up having its parent anchor
in just the same place. The other gets aligned normally but needs not to have other things aligned with it. It has child anchor=parent anchor=parent
. (Although the alignment isn't quite right for reasons I'm not certain about.)
@SašoŽivanović Now you tell me that, I can see it. I think it is just that square brackets don't look obviously different in the two fonts except when you've got both side-by-side to compare.
4:21 PM
@SašoŽivanović I am using a lot of booleans because they are easy to combine into tests and straightforward to keep track of, basically. I don't understand why it didn't occur to me earlier. Registers are phenomenally useful and hugely simplify things in my case. Greatly reduce the need to keep saying
for root={for tree={...}}
and/or using TeX stuff to count etc., which I was doing. This seems much more self-contained/cleaner..
You're the author of texdoc, right? Some people have reported that texdoc forest gives them the code (forest.pdf) instead of the manual (forest-doc.pdf), which is surely not what most people would want. I was suggested to rename the files. Would renaming the code to forest-code.pdf do the trick? (I'm not eager to part with my forest.dtx, but ah well...) Or is there something you can do?
3 hours later…
9:17 PM
@SašoŽivanović I meant that using the code you suggested, I'm still using
forest@last@node
in the definition and then using last dynamic node
. If it changes, won't it break either way? Whether I just use forest@last@node
or I use forest@last@node
in defining last dynamic node
and then use last dynamic node
?
9:42 PM
2 hours later…
11:53 PM
« first day (121 days earlier) ← previous day next day → last day (438 days later) »