Child split pane is "lost" as a result of resizing its parent split pane about micro HOT 5 OPEN

And there is no way to make it accessible again (no way to make its width non-zero again).

I understand what you mean but technically I found that user can access it again and even make it visible

1. It is still in the nodes tree so I tried to apply Ctrl+w several times and I cycled to the invisible split. It is invisible but you can still write there and perform actions: save file, set buffer local options... but I won't make it visible

2. Close the fourth split and you will see the third

• Init layout
  
• After bug layout
  
• After closing fourth split layout
  

from micro.

You are right, but I think all that is not so important. What's important is how to fix it. (I assume you agree that this is a bug that needs to be fixed?)

I think we have 2 issues here, likely related to each other:

1. We need to ensure (recursively) that when resizing a pane, not only the width of this pane never goes below zero, but also widths of any its child panes never go below zero. E.g. if a vertical split pane has 3 child vertical split panes, then if we resize the parent pane and its width narrows down to 3 characters, we should not allow resizing it further.
2. Although micro seemingly implements proportional scaling of child panes when resizing a parent pane, this proportional scaling does not work quite as it should.

from micro.

Hm, from user perspective we could allow resizing till the content isn't visible any longer, but what we shouldn't allow is to resize it that low to hide the split divider, because that's the only anchor for any further access.

from micro.

Yes, that's exactly the issue.

from micro.

1. We need to ensure (recursively) that when resizing a pane, not only the width of this pane never goes below zero, but also widths of any its child panes never go below zero. E.g. if a vertical split pane has 3 child vertical split panes, then if we resize the parent pane and its width narrows down to 3 characters, we should not allow resizing it further.

Maybe it can be done by returning from child maximum available space before 0 and if it is smaller that available space to neighbor/screen border...?

from micro.