@Eric I'm afraid I cannot reproduce the error (well, warning). Also not by \inputing an invalid file, as you suggested. Maybe it's a question of some auxiliary files, or maybe your editor gets confused?

Send the log file when it happens again ...

@SašoŽivanović Thanks. Apparently not thought about it enough, though. Anyway, I can't now compile even my first example and I have no idea what the code is even supposed to do any more. I thought I might do better with before packing node, but that did not go at all well. I probably should revert again back to a version which only fails to compile with later examples. I have two kinds of tree. I can fix one or the other but not both...

@SašoŽivanović Maybe compiling from the command line would help? Kile routinely opens inappropriate files when I get compilation errors. (Usually they are my own, but mostly it is my current document which contains the problem and not the class or package.) It also opens generated files from other packages. The command line is much easier when it doesn't work....

@Eric ^^

@SašoŽivanović Thanks. This was actually so slow that I only tried to use part of it anyway. (Unsuccessfully.)

I tried to reduce the pgfmath and that doesn't seem to be have been a good idea.

I keep remembering why I did things and then can't remember how I did them.

@SašoŽivanović I've been trying to count the lines using your code - well, not quite yours. Mine doesn't work, obviously. I need to somehow not count when I've got certain kinds of nodes, even if y increases. That's fine. But then I need to somehow count if there's a 'real' node before y increases again. Right now the output is weird - no errors, it just skips lines. I guess that I could add a condition to the sort. Maybe that would be easiest. Or I could refuse to support biconditionals...

Not sure why ^^ is happening, though ;).

@SašoŽivanović okay, this is weired! I deleted all my auxilary files and compile entirely new, but I still get those two ghost warnings. btw: you can find the log-files in the folder "built". I am using TeXstudio. But for some reason I don't get those errors in Texmaker....

@SašoŽivanović I even reinstalled TeXstudio with clearing all user related log files and stuff... but still... :( this is frustrating.

@SašoŽivanović @cfr this it how it looks like

since there is no warning message I am even not able to get rid of it with the silence package :D

@Eric Ok, so I guess it's TeXStudio that is confused. I have an idea why, as AuxTeX that I use once got in a similar pickle.

These programs analyze log files to see where the errors occur. TeX outputs (<filename> when it start inputting a file, and ) when the file is closed, so these programs search for ( and ). Now, they might get confused as some packages output unrelated (s and )s (even if they are matched ... this really depends on the regexp that a particular program uses). Actually, forest does that too, as it's description is Drawing (linguistic) trees.

Workaround that worked for me was to say \typeout{)} just at the beginning of the document. I suspect that in your case, immediately after loading forest might be even better.

@cfr I've added a conditional within every step and it it sems to work. (My conditional is just a dummy: when content of a node is dont, it's not enumerated.)

  create line numbers and justifications/.style={
    % sort the nodes top-to-bottom, left-to-right
    % the plan is to walk this sorted nodewalk and increase the line number when y changes
    sort by={y,-x()}, for sort'={tree}{
      % create the first line number & justification manually
      % (nodewalk step !back doesn't work on the first node)
      tempcounta'=1,
      new line number/.process args={RO}{tempcounta}{y},
      new justification/.process args={ROO}{tempcounta}{just}{y},
      % after the first step, change the every step register to include the conditional

And this code assumes that the first node of the nodewalk (above, root) should always be enumerated. If that's not the case, in general, you should put the same conditional around the code that gets executed for the first node (just before every step'=....

@SašoŽivanović unfortunately this workaround doesn't fix the issue for me... I just inserted \typeout{)} below the forest package load, right? and I also tested it right at the beginning of the document. but the warnings still occur, even after deleting the .aux file. do you have another idea how to fix this?

@Eric I'm afraid this exhausts my set of ideas for now. If I get another brainwave, I'll let you know.

alright, I appreciate your help.

or do you have maybe an idea how I could get it silence?

is it possible to silence forest.sty perhaps?

@Eric I don't see how that would work ... I mean, you do want to learn when you have errors ... they are just reported in the wrong place.

of course I want to learn of errors and warnings, but these are not quite expressive. :P well, that probably means trying to ignore those for now...

@SašoŽivanović I am currently trying this which seems to work:

define long step={proof tree camau}{}{% from saso's code (forest2-saso-ptsz.tex)
    r, sort by={y,(proof_tree_phantom()==0),-x()}, sort'=descendants
  },

and then

proof tree creu nodiadau={%
        if={((line_numbering)==1) || ((justifications)==1)}{% count the levels if necessary
          proof tree rhif lefelau'=0,
          for proof tree camau={%
            if={((proof_tree_rhifo()==1)&&(proof_tree_phantom()==0))&&(level()>0)}{%
              if={y()<y("!back")}{%
                proof tree rhif lefelau'+=1,
                line no'/.register=proof tree rhif lefelau
              }{%
                line no'/.register=proof tree rhif lefelau
              },

...

Although nodes do not know their line numbers this way. I'm not sure if I have to typeset them again for this to work. At least, they don't know them in the sense that a tikz option using them fails. But I was only using that for debugging, really. I would like line no to be read only, but I don't think that's possible.

@SašoŽivanović What does every step' do? I couldn't find it in the manual, but maybe I missed it. (As opposed to every step.)

@SašoŽivanović please don't ask why, but the warnins are gone. Just to hopefully let you sleep better :D

@cfr every step is a keylist register, so the usual rules for keylist options/registers apply. every step' sets the keylist, while every step appends to it.

@cfr Read only, not without some hacking ;-) But then very persistent users might hack your hack anyway ;-)

@Eric :-)

@cfr I realize now why my first thought was to put a filter inside sort'! But then I forgot about it ... So the idea is to say something like sort'={filter={tree}{!strequal(content(),"dont")}}{...}. Then the non-relevant nodes won't be even sorted, let alone walked.

Now, the problem is that there seems to be some interference between filter and sort. I'm sorting it out, pun intended;) but the problem is that I have to move right now and won't be able to work on it until tomorrow afternoon. Sorry!

Btw, having a level()>0 is a great idea, precisely because you do want to get the root node walked.

@SašoŽivanović Wow! You must be much more efficient at moving than me.

@SašoŽivanović I'd be fine with very persistent users hacking my hack. First, this is always true. Second, I don't especially want to stop anybody changing it if they really want to. I'm more concerned about people thinking it is a good way to move things or changing it inadvertently. I'd like a read-only-unless-you-really-mean-it status ;).