Fixing missing case for handling root node for splitting #3983

Neko-Box-Coder · 2026-01-31T15:27:40Z

At the beginning, the node tree looks like this, where x = STUndef

// <STUndef> <Coords> <ID> <Parent>
Node Tree:
 x{0 0 211 46} 1 root🍁

When performing VSplit or HSplit at the beginning, we check if we are root node using STUndef, in which we will always put the new split as its children, then we set the node kind for the root node. Which then looks like this:

Node Tree:
 -{0 0 211 46} 1 root
	|{0 0 105 46} 1 1🍁
	|{105 0 106 46} 2 1🍁

Since we have set root node kind after the initial split, the special handling for the root node using STUndef will no longer be valid.

When using quit instead of unsplit, you can only get to the following node tree, and doing quit on the child will quit micro entirely.

Node Tree:
 -{0 0 211 46} 1 root
	|{0 0 211 46} 1 1🍁

However, if you are using unsplit, you can actually go back to the original state, like this:
One pane left:

Node Tree:
 -{0 0 211 46} 1 root
	|{0 0 211 46} 1 1🍁

After unsplit:

Node Tree:
 -{0 0 211 46} 1 root🍁

The fix is simply check if the parent is nil to determine if we are the root node or not.

I have also rearrange VSplit last if condition to match HSplit where we are treating current node as non-leaf node and add the new split to it's children.

Also updated the String() to show the parent node id for easier debugging.

Fixes #3980

JoeKar · 2026-01-31T16:18:59Z

When this is the initial state...

Node Tree:
 x{0 0 211 46} 1 root🍁

...and this the state after the first unsplit (back to just one pane)...

Node Tree:
 -{0 0 211 46} 1 root
	|{0 0 211 46} 1 1🍁

...shouldn't we flat this state into the initial state already to return to the initial state with this one and last split?

Node Tree:
 x{0 0 211 46} 1 root🍁

So that any further unsplit doesn't do anything, even not in the background.
Because right now we can once again unsplit this tree to the initial state, while the user presentation doesn't change.

Besides of that the rearrangement of VSplit() is a good idea, because it fooled me while debugging. 😅

internal/views/splits.go

Neko-Box-Coder · 2026-01-31T16:41:35Z

So that any further unsplit doesn't do anything, even not in the background.
Because right now we can once again unsplit this tree to the initial state, while the user presentation doesn't change.

I did think about this while creating the PR fix. The thing is I think this behavior has always been a valid state for the root node, whether it is before or after my flatten() fix.

One of the trick point is that the flatten() function needs to access the grandparent (parent's parent) of the node being unsplit. Which won't work in this case since the grandparent of the root node child doesn't exist:

Node Tree:
?? <-- unflatten will try to access this.
 -{0 0 211 46} 1 root
	|{0 0 211 46} 1 1🍁

I probably could change the logic of flatten() but I don't remember anything on how it works to be frank 😂, simply because it is a complicated logic.

I vaguely remember the first iteration of flatten() was recursive, which might have worked on this scenario but I think we refactored/removed it due to how complicated it is.

So in short, in theory yes I agree with you. In practice I will probably need to spend more time to recover my memory on how it works and see if I can modify it without making it recursive. And also need to test it as well.

I can take a look at it at some point but can't promise anything for now. If you want to have a try, go for it :)

…-editor#3980

JoeKar · 2026-01-31T17:51:04Z

If you want to have a try, go for it :)

func (n *Node) flatten() {
	if len(n.children) != 1 {
		return
	}

	if n.parent == nil {
		n.Kind = STUndef
		n.children = n.children[:0]
		return
	}
	[...]

Not 100% sure, if this covers all and everything, but looks good from behavior and node printing.

dmaluka · 2026-02-01T22:12:46Z

internal/views/splits.go

 		return 0
 	}
-	if n.Kind == STUndef {
+	if n.parent == nil {


The next commit seems to make this change unneeded? I mean, if we guarantee that the root is always STUndef, why not use it? Otherwise, if we don't use STUndef, why do we even need it?

And IMHO using STUndef makes the code a bit more readable.

Minor thing but I would think n.parent == nil is more straightforward no? Since that is the definition of root node.

A child node can be of type STUndef (Although it is a bug), but a child node definite cannot have a node parent of nil right?

Then, again, why need this STUndef constant at all?

Although, after more thought, - ok, let's keep it (even though it is causing a bit of redundancy), just to let it reflect that it is indeed undefined whether it is horizontal or vertical.

Then, again, why need this STUndef constant at all?

Nah, we don't need it. Didn't do it cuz I only did minimal change just to fix the issue.

It doesn't matter if it is horizontal or not if it gets changed anyway. If we agree to remove it, I can do it :)

dmaluka · 2026-02-02T00:46:28Z

Just tried testing this PR... Apparently it is fixing one crash but introducing another one, which is even easier to reproduce: for example:

VSplit
Focus the 1st (i.e. leftmost) split.
Unsplit

Result:

Micro encountered an error: runtime.errorString runtime error: invalid memory address or nil pointer dereference
runtime/panic.go:262 (0x477659)
runtime/panic.go:261 (0x477629)
github.com/zyedidia/micro/v2/internal/action/tab.go:385 (0x8dd494)
github.com/zyedidia/micro/v2/internal/action/actions.go:2045 (0x8c474e)
github.com/zyedidia/micro/v2/internal/action/bufpane.go:567 (0x8cbbad)
github.com/zyedidia/micro/v2/internal/action/tab.go:224 (0x8c9fb1)
github.com/zyedidia/micro/v2/internal/action/bufpane.go:183 (0x8c9dd9)
github.com/zyedidia/micro/v2/internal/action/bufpane.go:33 (0x8c9d71)
github.com/zyedidia/micro/v2/internal/action/bufpane.go:546 (0x8cb919)
github.com/zyedidia/micro/v2/internal/action/bufpane.go:464 (0x8cb3bc)
github.com/zyedidia/micro/v2/internal/action/tab.go:337 (0x8dcd45)
github.com/zyedidia/micro/v2/internal/action/tab.go:141 (0x8dbe65)
github.com/zyedidia/micro/v2/cmd/micro/micro.go:542 (0x90d06a)
github.com/zyedidia/micro/v2/cmd/micro/micro.go:481 (0x90cbb0)
internal/runtime/atomic/types.go:194 (0x441f4b)
runtime/asm_amd64.s:1700 (0x47d341)
 
If you can reproduce this error, please report it at https://github.com/zyedidia/micro/issues

JoeKar · 2026-02-02T18:05:23Z

internal/views/splits.go

+		*n = *n.children[0]
+		n.parent = nil


Ah, yes...right. We overwrite the root node with the last remaining children, by which it receives the id of the children, with which it is identified in the tab resize.
But still we should keep the removed n.Kind = STUndef, otherwise func (n *Node) String() wouldn't print what we expect from the new root. Otherwise in case we agree to remove STUndef we've to adjust this function to print "/" on n.parent == nil.

Am I right that we should keep the fault in tab.go#L382 to identify that something went wrong, because GetNode() returns nil by intention in case the pane ID wasn't found?

Otherwise in case we agree to remove STUndef we've to adjust this function to print "/" on n.parent == nil.

True. Forgot about that change when I made this change. Will add it back if we want to leave STUndef as it is.

Am I right that we should keep the fault in tab.go#L382 to identify that something went wrong, because GetNode() returns nil by intention in case the pane ID wasn't found?

Not sure what fault you are referring to. t.GetNode(p.ID()) should never fail no?

Not sure what fault you are referring to. t.GetNode(p.ID()) should never fail no?

But it can splits.go#L140 and this is intended, when the given ID isn't present at the related nodes.

Will add it back if we want to leave STUndef as it is.

I vote for keeping it too.

Not sure if I am missing something but the given id should always be present for the node unless something is wrong no?

I vote for keeping it too.

I vote for removing it :) since it's sole purpose is to identify root node and that can be done by just checking if parent exists or not.

Just need @dmaluka 's vote or anyone else interested.

I vote for keeping it, so that we don't need to meaninglessly pass STVert or STHoriz to NewNode() when creating the root node.

Okay got it. Added back the n.Kind = STUndef

You don't like this n.Kind = STUndef statement, right? 😉

@JoeKar
Forgot to explain it why I removed n.Kind = STUndef after adding it 😅

I initlially kept it when adding

for _, c := range n.children { c.parent = n }

So like

if n.parent == nil { *n = *n.children[0] n.parent = nil n.Kind = STUndef for _, c := range n.children { c.parent = n } return }

for fixing the crash @dmaluka observed.

Then when I was testing it, it failed to resize the last split correctly when unsplitting the splits one by one, where the last split only took half of the screen instead of taking the whole screen.

After some debugging, I realized the kind for the root node cannot be undef when we remove the intermediate one since it can have more than one grandchildren.

Like so:

2026/02/03 18:46:40 Node Tree: -{0 0 211 46} 1 0 |{0 0 105 46} 1 1🍁 |{105 0 106 46} 2 1 -{105 0 106 15} 2 2🍁 -{105 15 106 15} 3 2🍁 -{105 30 106 16} 4 2🍁

Becomes this if I removed leaf node ID 1:
(forget about the coords and parent id. This is just for demo purposes, I cba to rebuild micro to get the logs)

2026/02/03 18:46:40 Node Tree: -{0 0 211 46} 1 0 -{105 0 106 15} 2 2🍁 -{105 15 106 15} 3 2🍁 -{105 30 106 16} 4 2🍁

Looking at the tree before being flattened.
If I unsplit leaf node ID 1, the unsplit will flatten the intermediate non leaf node ID 2 with grandparent leaf nodes 2, 3 and 4. If the kind for the root node is Undef, the resize won't work correctly.

dmaluka · 2026-02-02T22:26:50Z

Another crash, observed with the newest version of this PR:

Open a vertical split.
In this newly opened split (i.e. on the right), open a horizontal split.
Focus the vertical split on the left, and open a horizontal split in it too (so that the screen becomes nicely split into 4 quarters).
Focus the vertical split on the right (i.e. any of its two horizontal sub-splits).
Start closing all splits one by one.

Result:

Micro encountered an error: runtime.errorString runtime error: invalid memory address or nil pointer dereference
runtime/panic.go:262 (0x477659)
runtime/panic.go:261 (0x477629)
github.com/zyedidia/micro/v2/internal/views/splits.go:500 (0x8a16bf)
github.com/zyedidia/micro/v2/internal/views/splits.go:479 (0x8a15a7)
github.com/zyedidia/micro/v2/internal/action/actions.go:2042 (0x8c4654)
github.com/zyedidia/micro/v2/internal/action/actions.go:1903 (0x8c3b34)
github.com/zyedidia/micro/v2/internal/action/actions.go:1940 (0x8c3d3a)
github.com/zyedidia/micro/v2/internal/action/bufpane.go:567 (0x8cbc0d)
github.com/zyedidia/micro/v2/internal/action/tab.go:224 (0x8ca011)
github.com/zyedidia/micro/v2/internal/action/bufpane.go:183 (0x8c9e39)
github.com/zyedidia/micro/v2/internal/action/bufpane.go:33 (0x8c9dd1)
github.com/zyedidia/micro/v2/internal/action/bufpane.go:546 (0x8cb979)
github.com/zyedidia/micro/v2/internal/action/bufpane.go:464 (0x8cb41c)
github.com/zyedidia/micro/v2/internal/action/tab.go:337 (0x8dcda5)
github.com/zyedidia/micro/v2/internal/action/tab.go:141 (0x8dbec5)
github.com/zyedidia/micro/v2/cmd/micro/micro.go:542 (0x90d0ca)
github.com/zyedidia/micro/v2/cmd/micro/micro.go:481 (0x90cc10)
internal/runtime/atomic/types.go:194 (0x441f4b)
runtime/asm_amd64.s:1700 (0x47d341)
 
If you can reproduce this error, please report it at https://github.com/zyedidia/micro/issues

Neko-Box-Coder · 2026-02-02T23:29:04Z

Another crash, observed with the newest version of this PR:

1. Open a vertical split.

2. In this newly opened split (i.e. on the right), open a horizontal split.

3. Focus the vertical split on the left, and open a horizontal split in it too (so that the screen becomes nicely split into 4 quarters).

4. Focus the vertical split on the right (i.e. any of its two horizontal sub-splits).

5. Start closing all splits one by one.

Result:

Micro encountered an error: runtime.errorString runtime error: invalid memory address or nil pointer dereference
runtime/panic.go:262 (0x477659)
runtime/panic.go:261 (0x477629)
github.com/zyedidia/micro/v2/internal/views/splits.go:500 (0x8a16bf)
github.com/zyedidia/micro/v2/internal/views/splits.go:479 (0x8a15a7)
github.com/zyedidia/micro/v2/internal/action/actions.go:2042 (0x8c4654)
github.com/zyedidia/micro/v2/internal/action/actions.go:1903 (0x8c3b34)
github.com/zyedidia/micro/v2/internal/action/actions.go:1940 (0x8c3d3a)
github.com/zyedidia/micro/v2/internal/action/bufpane.go:567 (0x8cbc0d)
github.com/zyedidia/micro/v2/internal/action/tab.go:224 (0x8ca011)
github.com/zyedidia/micro/v2/internal/action/bufpane.go:183 (0x8c9e39)
github.com/zyedidia/micro/v2/internal/action/bufpane.go:33 (0x8c9dd1)
github.com/zyedidia/micro/v2/internal/action/bufpane.go:546 (0x8cb979)
github.com/zyedidia/micro/v2/internal/action/bufpane.go:464 (0x8cb41c)
github.com/zyedidia/micro/v2/internal/action/tab.go:337 (0x8dcda5)
github.com/zyedidia/micro/v2/internal/action/tab.go:141 (0x8dbec5)
github.com/zyedidia/micro/v2/cmd/micro/micro.go:542 (0x90d0ca)
github.com/zyedidia/micro/v2/cmd/micro/micro.go:481 (0x90cc10)
internal/runtime/atomic/types.go:194 (0x441f4b)
runtime/asm_amd64.s:1700 (0x47d341)
 
If you can reproduce this error, please report it at https://github.com/zyedidia/micro/issues

Nice one. Thanks for finding out all the crashes, appreciated. Hopefully, it is good this time.

JoeKar · 2026-02-03T19:10:57Z

internal/views/splits.go

-		marker := "|"
+		marker := "/"
 		if n.Kind == STHoriz {
 			marker = "-"
+		} else if n.Kind == STVert {
+			marker = "|"
+		}
+		var parentId uint64 = 0
+		if n.parent != nil {
+			parentId = n.parent.id
 		}


I think we should slightly rework this:

var marker string var parentId uint64 = 0 if n.parent == nil { marker = "/" } else { if n.Kind == STHoriz { marker = "-" } else if n.Kind == STVert { marker = "|" } parentId = n.parent.id }

What do you think?

Neko-Box-Coder mentioned this pull request Jan 31, 2026

The 'Unsplit' action causes the app to crash #3980

Open

JoeKar reviewed Jan 31, 2026

View reviewed changes

internal/views/splits.go Outdated Show resolved Hide resolved

Fixing missing case for handling root node for splitting, fixes micro…

a87f3dd

…-editor#3980

Neko-Box-Coder force-pushed the FixRootSplitBug branch from c8a121f to a87f3dd Compare January 31, 2026 16:47

JoeKar changed the title ~~Fixing missing case for handling root node for splitting, fixes #3980~~ Fixing missing case for handling root node for splitting Jan 31, 2026

JoeKar approved these changes Feb 1, 2026

View reviewed changes

dmaluka reviewed Feb 1, 2026

View reviewed changes

Neko-Box-Coder force-pushed the FixRootSplitBug branch from 0a07c9e to c554fa7 Compare February 2, 2026 12:05

JoeKar reviewed Feb 2, 2026

View reviewed changes

Neko-Box-Coder force-pushed the FixRootSplitBug branch from c554fa7 to 3789835 Compare February 2, 2026 21:15

Adding special case for root node for flatten()

49fd03c

Neko-Box-Coder force-pushed the FixRootSplitBug branch from 3789835 to 49fd03c Compare February 2, 2026 23:26

JoeKar reviewed Feb 3, 2026

View reviewed changes

Fixing missing case for handling root node for splitting #3983

Are you sure you want to change the base?

Fixing missing case for handling root node for splitting #3983

Conversation

Neko-Box-Coder commented Jan 31, 2026 • edited by JoeKar Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JoeKar commented Jan 31, 2026

Uh oh!

Uh oh!

Neko-Box-Coder commented Jan 31, 2026

Uh oh!

JoeKar commented Jan 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Neko-Box-Coder Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dmaluka commented Feb 2, 2026

Uh oh!

JoeKar Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JoeKar Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Neko-Box-Coder Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dmaluka commented Feb 2, 2026

Uh oh!

Neko-Box-Coder commented Feb 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Neko-Box-Coder commented Jan 31, 2026 •

edited by JoeKar

Loading

JoeKar commented Jan 31, 2026 •

edited

Loading

Neko-Box-Coder Feb 2, 2026 •

edited

Loading

JoeKar Feb 2, 2026 •

edited

Loading

JoeKar Feb 2, 2026 •

edited

Loading

Neko-Box-Coder Feb 3, 2026 •

edited

Loading