@JoeKar @dmaluka

I have various plugins that implement native tooltips in the text editor.

They rely on changing the panes' view in a tab to keep the layout after adding a tooltip, so all effects of Resize() are reversed and I can draw buffers on top of each other.

While trying to give mouse support —it reported the wrong buffers because of how that logic is implemented, more on this later— I found that marking all the nodes as non-resizable with SetResize() method of Node avoids saving the layout and simplifies the plugin logic.

The problem occurs when, deep in the call stack, after calling bufpane:HSplitIndex() the canResize field from the parent node is not carried to the nodes that are created, specifically the child that will keep its buffer.

I see this happening in various cases but I will report the simple one: only one pane.

tab after HSplitIndex::NewBufPaneFromBuf {0 0 92 11} 1 0🍁
HSplit::STVert
vHSplit::isLeaf branch
after HSplitIndex::HSPLIT |{0 0 92 11} 1 0
	-{0 0 92 5} 1 1🍁
	-{0 5 92 6} 2 1🍁

When I split downward, the top child -{0 0 92 5} 1 1🍁 should inherit the parent's canResize since it carries the parent ID; and because the parent can't resize, that child should also keep its size and not resize.

My knowledge of this part of the codebase is almost zero, so I do not know collateral effects of the prop* fields, but they also seem like they should be inherited.

diff --git a/internal/views/splits.go b/internal/views/splits.go
index d310db21..dcda9faa 100644
--- a/internal/views/splits.go
+++ b/internal/views/splits.go
@@ -65,10 +65,17 @@ func NewNode(Kind SplitType, x, y, w, h int, parent *Node, id uint64) *Node {
 	n.children = make([]*Node, 0)
 	n.parent = parent
 	n.id = id
-	if parent != nil {
+	n.propW, n.propH = 1, 1
+
+	if parent != nil { // not a root node
 		n.propW, n.propH = float64(w)/float64(parent.W), float64(h)/float64(parent.H)
-	} else {
-		n.propW, n.propH = 1, 1
+		if parent.id == id { // favorite child?
+			n.canResize = parent.canResize
+			if !parent.canResize {
+				n.X, n.Y, n.W, n.H = parent.X, parent.Y, parent.W, parent.H
+			}
+			n.propScale = parent.propScale // not sure about this one.
+		}
 	}

 	return n

Regarding the mouse issue, the UI rendering assumes —rightfully— that the last pane is drawn on top of the others by execution order.

But the mouse-click detection logic iterates bottom (0) to top (N) instead of reversing that order —again, rightfully, because overlapping was not taken into account— so the Z-axis/depth is not respected.

This shouldn't break anything because I don't think anyone is doing weird things with panels and overlapping was not considered possible in the codebase. Reversing the loop iteration is sufficient.

diff --git a/internal/action/tab.go b/internal/action/tab.go
index fa991f3e..be935948 100644
--- a/internal/action/tab.go
+++ b/internal/action/tab.go
@@ -305,8 +305,8 @@ func (t *Tab) HandleEvent(event tcell.Event) {
 			}

 			if wasReleased {
-				for i, p := range t.Panes {
-					v := p.GetView()
+				for i := len(t.Panes) - 1; i >= 0; i-- {
+					v := t.Panes[i].GetView()
 					inpane := mx >= v.X && mx < v.X+v.Width && my >= v.Y && my < v.Y+v.Height
 					if inpane {
 						t.SetActive(i)

I did not want to make a PR or open an issue because I wanted to discuss this new behaviour (buffer overlapping) inside the editor first. And as I prefer to stay on the stable release, these changes will not be available for my plugins until the next release in a few months; I am in no rush.

I believe the changes to canResize and inheritance behaviour are or should be coherent with the intended behaviour for the plugin.

And for the mouse, it should not affect anything, but since overlapping is not the planned behaviour it doesn't make much sense until discussed.