As promised: editing. Now the algorithm correctly classifies the situation when you rename a node somewhere in the tree. &diffest2

I haven't shown you how moved content looks like when it's more than a leaf node in the last post. That's because there is a technically-cheaper solution that instead inserts a new parent node and removes the old parent node to avoid duplication (testcase 410). While a correct solution, it is not intuitive and the way I'm displaying it does it no favors.
However I just realized that if I put enough stuff between the old and new place the subtree attaches to, the cheapest solution will end up being a move again. And so I decided to show you all how that looks (testcase 411). Borders following the text lines aren't pretty either, sadly.
Anyway, back to what I was doing before I came up with that which was adding functionality that allows you to edit a node in the tree. &diffest2

I've improved on the testcases from two posts ago by highlighting both places the moved node shows up as one. You might remember that I tracked moved content the same way in last year's exploration. &diffest2

You might have noticed that I conspicuously left out a few test cases in the screenshots I've shared up to now. That was because the results didn't look right. The core part of my comparison algorithm works itself in a depth-first way through the nodes and is blind to the rest of the tree structure. When the last child-node of a given parent changes depth that becomes a problem. I've spent yesterday afternoon adding a bunch of code for dealing with these cases. At the point in time where I'm turning the result back into a tree I add additional nodes that represent the new or old parents. This doesn't feel like a good solution though, since now we have nodes duplicated in the merged tree. There is a lot more visualization work that needs to be done for this project than I realized. &diffest2

I enhanced my cost function by adding penalties for undesirable solutions. This is to ensure that all these test cases look as obvious as possible. &diffest2

My previous screenshot could have been generated by simply passing the two inputs to a naive text-based diff tool. They weren't, but they could have. That's why I said "nothing exciting".
This new set of tests now works with actual trees. I'm adding or removing both leaf nodes as well as nodes inside the tree (branch nodes). As you can see, the appropriate areas are marked as insertions or deletions respectively. &diffest2

Dear guests,

it is my honor to welcome you all to this year's Visibility Jam, right here in #project-showcase or wherever you're reading this around the web.

My fellow jammers and I will be taking this long weekend to bring light into darkness and explore the invisible. You'll excuse us if our posts are less polished than usual, we take longer to engage in discussions, or resort to only reacting with emoji. We'll have all the time in the world to talk about our projects, after we've caught up on sleep.
-# this is a joke. please sleep enough.

To my fellow jammers: I wish you all success with your projects, few bugs, and of course good luck and have fun!

I'll be spending this weekend looking at trees. The digital kind. Your filesystem is (mostly) a tree, but the content of individual files is also often structured as a tree. Specifically I want to explore how to compare two versions of the same tree and highlight differences. This morning I've built a test setup and started producing results for some of the simplest trees there are. In the screenshot I've got one test per row, and in each row the two trees that are input into the algorithm, and on the right the resulting output. So far, nothing exciting. Next up, I want to look at trees with more than one level. &diffest2