Formatter.RenderTree.Json

Serialise the render tree to JSON for debugging.

Exposed via the CLI's gren-format --rt, and the Box-stage analogue of Formatter.Logical.LPTJson's --lpt. The two dumps are deliberately close in shape, because the trees are: the useful way to read this one is beside the --lpt of the same file.

What it shows that --lpt cannot is the whole reason the flag exists. Four of the renderer's decisions genuinely need to know how the author laid the code out, and Formatter.RenderTree.lower answers them once, on the way past the stage barrier, as booleans -- see the "five facts that were rows" in Formatter.RenderTree. They do not exist in the LPT, and by the time there is a Box to dump they have already been consumed, so before this flag the only way to learn one was to read the LPT's source rows and re-derive it by hand. That is exactly the re-derivation the barrier exists to make impossible, which makes doing it to debug the barrier a poor way to spend an afternoon.

The booleans arrive as one "flags" string, naming the ones that are set. The question anyone brings to this dump is "which nodes is it set on?", which greps by name whatever the encoding; what differs is how much of the file the answer is buried in. Five booleans spelled out is five lines per node, and a JSON array of the set ones is no better, since Json.encode 2 puts every element on its own line -- a space-joined string is the one spelling that costs a single line.

The key is always present, and always written from all five, so "" positively means "none of them" and a name's absence never means "not reported for this kind of node".

Positions are absent for a stronger reason: RenderNode and RenderShape do not carry any. If you want a row or a column, --lpt is the dump that has them.