Fix unable to perform proportional resize caused by chained parents after quiting a nested VSplit inside a HSplit

[Neko-Box-Coder]

When you do a HSplit, follow by a VSplit, then quit the last pane and do a HSplit again, the proportional resize won't work as expected.

Currently you will get a 50%, 25%, 25% HSplits.
Instead it should be 33%, 33%, 33%.

This problem is caused by failing to resolve chained parents and the resize is called on the "wrong" parent.

The patch fixes chained parents by simplifying the tree when unsplittng.

This problem can be visualized by calling the String() on the current tab. In lua, it will look something like this:

function MyFunction(bp)
    micro.Log("Node Tree:", bp:Tab():String())
end

So if you have something like this

-------------------------------------------------------------
|                                  |                        |
|                                  |             2          |
|              1                   |----------------------- |
|                                  |                        |
|                                  |             3          |
-------------------------------------------------------------

the tree looks like this:

-{0 0 211 46} 1
     |{0 0 105 46} 1🍁
     |{105 0 106 46} 2
         -{105 0 106 23} 2🍁
         -{105 23 106 23} 3🍁

If you quit the 3rd pane, the tree will look like this:

-{0 0 211 46} 1
    |{0 0 105 46} 1🍁
    |{105 0 106 46} 
        -{105 0 106 46} 2🍁

Then if you do a VSplit, the tree will look like

-{0 0 211 46} 1
    |{0 0 105 46} 1🍁
    |{105 0 106 46} 2
        -{105 0 106 46} 2
            |{105 0 53 46} 2🍁
            |{158 0 53 46} 4🍁

Which fails the resize since it is calling on a chained parent

After applying the patch, it will "simplify" the tree after quitting the 3rd pane

-{0 0 211 46} 1
    |{0 0 105 46} 1🍁
    |{105 0 106 46} 2🍁

Then when you do another VSplit, it will look like this:

-{0 0 211 46} 1
    |{0 0 70 46} 1🍁
    |{70 0 70 46} 2🍁
    |{140 0 71 46} 3🍁

and the resize will work as expected since it will be called on the correct parent.

[dmaluka]

Nice fix, thanks.

[dmaluka]

!successor.IsLeaf() here is redundant?

And actually successor.Kind == n.parent.Kind seems redundant too, it should always be true, unless we have a bug?

[dmaluka]

If we remove successor.Kind == n.parent.Kind above as redundant, we can update this comment like: "If the successor node has its own children, it means it is a redundant chained parent too, so replace it with its children."?

[Neko-Box-Coder]

Yeah, that is true. I wasn't thinking much when copying and pasting this part.

[dmaluka]

s/might have been updated/has been updated/
s/may have new siblings/have new siblings/

?

[dmaluka]

Maybe add a comment above this line: "Make sure the tree remains in a consistent state: any child node's kind (horizontal vs vertical) is the opposite of its parent's kind"?

Also why not rearrange the lines like this:

--- a/internal/views/splits.go
+++ b/internal/views/splits.go
@@ -495,10 +495,12 @@ func (n *Node) flatten() {
 	}
 
 	// Replace current node with its child node to remove chained parent
-	n.parent.children[ind] = n.children[0]
-
-	successor := n.parent.children[ind]
+	successor := n.children[0]
+	n.parent.children[ind] = successor
 	successor.parent = n.parent
+
+	// Maintain the tree in a consistent state: any child node's kind (horiz vs vert)
+	// should be the opposite of its parent's kind.
 	if successor.IsLeaf() {
 		successor.Kind = n.Kind
 	} else if !successor.IsLeaf() && successor.Kind == n.parent.Kind {