[Feature]: Something like an accordion mode for smart resizing of splits

[lougreenwood]

Similar Issues

• [X] Before filing, I have searched for similar issues.

Description

I usually work on a large monitor, but recently I was on a trip and needed to work only on my laptop screen. I was struck by how my laptop screen and large font size don't allow for much to be shown when I have my usual layout of vsplits.

Something that came to mind is that for this scenario, having all my splits automatically collapse (maybe not fully, maybe keep each sized to 10% or 300 px etc) and as I move through the splits the new current split would expand and each would collapse, something like this:

| 1              | 2 | 3 | 4 |

| 1 | 2              | 3 | 4 |  

| 1 | 2 | 3              | 4 |

| 1 | 2 | 3 | 4              |

In terms of how this might work:

• This would be a mode the user would toggle on / off
  • perhaps within the context of the current split, so if the user has only 4 v splits, toggling on will toggle on for all of those splits, if one of these splits is then h split, it would not auto grow / shrink unless it's also toggled on when that "v split with h split" is the current window and the user toggles the feature on
  • Depending on whether a view was mostly horizontal or vertical splits it would auto collapse only in the direction of majority splitting (e.g if I have 4 v splits, but 2 also have 2 h splits it would only collapse in the v direction).
  • Perhaps there would be a config to allow nested splits to inherit auto-collapse behaviour from their context, e.g the nested h splits in the above would also automatically collapse if the "inherit" setting is enabled
  • Perhaps there would also be a setting to specify a width at which auto-collapse behaviour is triggered, e.g if I set the width to 500 px or 25%, if all of my splits are above this there is no collapsing, but if all of my splits are below this width collapse turns on
  • Again, some way to force auto-collapsing on - even when above the threshold might be nice
• The user would be able to set a default amount to collapse the splits to in either fixed or proportional amounts - e.g collapsed_width = 100px and all of the collapsed splits are now 100px
• The user would be able to resize all of the collapsed splits on-the-fly (while in the currently active split) by simply resizing the current split... make the current split larger to shrink the collapsed ones, make the current split smaller to grow the collapsed ones, the new widths of the collapsed splits would be remembered for the current level of splits and override the default "collapse_width/height". This means that as the user navigates through the splits, the resized amount is remembered and used, not the default one)
  • the user would need a way to be able to reset collapse size back to default, e.g if they need to resize their nvim window or plug in an external monitor and their on-the-fly resizing was on longer useful
• The usual features would still work:
  • wrapping through tabs
  • swapping tabs
  • resizing (already mentioned above as being hijacked as the mechanism for adjust the width of the collapsed splits)

I realise that there's a lot to digest in the above, but I just wanted to provide a decent amount of context and help to sketch out the vision for this quite nuanced feature. I think it would need to feel very simple and intuitive for user interactions, which requires complexity being moved into the implementation.

🙇 Thanks!

[mrjones2014]

This sounds like functionality that is already implemented by other plugins, for example focus.nvim. Let me know if I got something wrong and I can reopen.

[lougreenwood]

Thanks for the suggestion @mrjones2014 - I'm not sure if focus.nvim fully meets the expectations, but it seems that it's on the right track. Unless I mis-understand it seems to be quite "focussed" on using the golden ratio as the basis of the split resizing.

But thanks for the tip!