@SašoŽivanović Is the following expected? Is there anything I can do to stop it?

\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.)

That is, I know that in my example, I can add

before drawing tree={for tree={edge path'={(!u.parent anchor) -- ++(0,-10pt) -| (.child anchor)}}}

to the preamble of the tree. But is there any way to modify the move by style so that it automatically picks up the settings from the for tree-{} bit of the preamble?

for tree={} ...

autoforward of some kind ...?

@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
        ]
      },
    },
  }
}

But it might be more trouble that it's worth ;-)

@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.)

This works even if the root has phantom, no edge, I think, since edge path is still set. And so is edge.... Not sure how safe it is, though.

Otherwise, I'm inclined to introduce a register which I pass to edge path/edge for the tree and in move by. But that duplicates Forest's stuff and strikes me as confusing.

This sounds as a good idea!

And by exposing / documenting the last node in the interface, we could even avoid the potential problems that you're mentioning.

edge path/.wrap pgfmath arg={##1}{edge_path("forest@last@node")},

@cfr Right now, the forest@last@node alias is package-internal, but I could either document it (maybe also remove @s), or introduce a new nodewalk step called something like last dynamic node.

Oh yes: this approach would copy the edge path of the node being replaced. Which, in my opinion, makes a lot of sense, generally.

@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?

So I'm thinking to simply have one optional argument, in (parenthesis), to be used like (stages={...}, namespace=..., parser=...).

Now the problem is that the new interface for temporary stages is already published. For two months. Do you think it would cause much trouble and anger if I changed it?

@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 appended 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?

@SašoŽivanović It is hard to tell. But

If it were done when 'tis done, then 'twere well
It were done quickly

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.

And those are the people most likely to read the new documentation, including the change log.

Could you make it so that if somebody writes

\begin{forest}[(...)]

they get a helpful error, though? @SašoŽivanović

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....

[OK. Generalising from one instance. I expect that syntax to mean....]

[And even though I know precisely why you can't have an optional argument in square brackets here having thought about it when designing prooftree.]

I see that we share the opinion, both pro and contra arguments. I'll try to post a new version this weekend.

@cfr It will include a last dynamic node nodewalk step. Hmm ... I can always complicate matters ... I could also create a dynamic nodes saved nodewalk, to be loaded by load. Do you think there is any chance that someone would want to visit all the created/removed/... nodes?

The brackets that signal optionallty are in the "normal" font. Those that are part of a bracket spec are in typewriter font. I believe that's a fairly standard approach.

@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...

Btw, I could implement key copy all options, if that would be handy for dynamically created nodes.

them use it? I guess.

Ah, so I guess dynamic nodes saved nodewalk would be handy for you, as you could simply say if in saved nodewalk={current}{dynamic nodes}{trie}{false}.

@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.

I see.

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.

@SašoŽivanović If you say so ;). I mean, I imagine it might simplify a construction like this:

where={(((proof_tree_line_number==0)&&(proof_tree_justification==0))&&(level>1))&&(proof_tree_phantom==0)}{%
            for name/.wrap 2 pgfmath args={{just ##1}{y=##2}}{int(level()+proof_tree_toing_by())}{y()}
          }{},

@SašoŽivanović trie should be true? It's not a new feature?

OMG!

New feature, not trie! ;-)

No I think you're right: when you have several categories of new nodes, your solution is simpler in the end. You'd still have to test for category anyway.

@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..

@PauloCereda I just realized I didn't tag this duck properly, so I repeat the question.

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?

@cfr Good to hear that!

@SašoŽivanović forest@last@node works nicely. Is it safe to use this? I can wait if you are planning to break it ;).

\forestset{
  define long step={last dynamic node}{style,must start at valid node=false}{%
    typeout={DEBUG},
    name=forest@last@node
  }
}

edge path/.pgfmath={edge_path("!last dynamic node")},

Btw, no need for .wrap pgfmath arg in this case.

And note the !.

And obviously, you can remove the DEBUG statement ...

@SašoŽivanović That also works. Is that better than using forest@last@node directly?

Yes. In case I change the implementation some day.

@SašoŽivanović Sorry, I missed your note. :) An email will arrive in your inbox. :)

@SašoŽivanović But I'm still using it in the definition....

I guess it won't hurt ... but I'm not lending my shoulder to cry on, if it does some day ;-))))

I've been a good boy today, I just have one more thing to fix for v2.0.2. (I think.) So the forthnight plan is working very nice! ;-)

@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?

Sorry I misunderstood. The code I gave you (definition of last dynamic node) is already in v2.0.2. Safe to use..

@SašoŽivanović Oh, I see. OK. Thanks. So I can take the definition out when you push 2.0.2 to CTAN and then I won't be directly using an internal command. Good ;).