Add flex resize, focus mode, hard-coded limits for now

[Termina94]

I have been playing around with different solutions to this issue and the nicest way I have found is using a flex-like approach where the parents container is split between the children bounds.

i.e | 1 | 1 | or | 2 | 1 | etc.

However this will not allow for reducing the size of a container that defaults to the value 1 and therefore all resizing will have to be managed by growing other children to make the one you want smaller which is not very intuitive.

For this draft example I have decided to hard code a slot limit per child of 20 and the each child starts with a default of 10. This feels much nicer but limits the accuracy of where you can resize your buffers to with a max of 20 potential sizes.

I have also added a focus toggle that will set the current buffers bounds to double the limit, ensuring it takes the majority of screen space allowing quick toggle to focus on different files which works quite nice with the flex approach.

As it stands this will be a draft until people have a play with the branch and we decide on a solution

https://github.com/helix-editor/helix/issues/1176

[David-Else]

Nice one!

Focus mode sounds great! Is it possible to have a 'zen' focus mode where the current window is centred with empty space either side, like https://github.com/folke/zen-mode.nvim ? Ideally the width would be 80 or maybe 100 characters. This is perfect for coding and writing while looking straight on at the monitor.

[Termina94]

The zen mode sounds very cool and is definitely worth having it's own issue in my opinion.

The focus mode here was more of a temporary expansion, to allow quick shortcut access to a good size buffer in a split without needing multiple inputs to slowly increase size.

Maybe focus is the wrong word and something like expand would be better suited for what this is doing

[erasin]

@Termina94 I'm a non-English speaking user and I try to be clear.

1. Less keymap memory. Would it be better we modify KeyMap like this：

        "C-w" => { "Window"
            ....
             "A-h"|"A-left" => shrink_buffer_width,
            "A-l"|"A-right" => grow_buffer_width,
            "A-j"|"A-down" => shrink_buffer_height,
            "A-k"|"A-up" => grow_buffer_height,
            "A-f" => buffer_expand_mode,
        },

       "space" => {
        ....
        "W" => { "Alter Window" sticky=true
            "h"|"left" => shrink_buffer_width,
            "l"|"right" => grow_buffer_width,
            "j"|"down" => shrink_buffer_height,
            "k"|"up" => grow_buffer_height,
            "f" => buffer_expand_mode,
        },
        ....
        }

2. config we need configure the size of each resize buffer.

3. resize direction We should care about the changes in the current window. The 'h/left' should be the boundary moving to the left and the 'l/right' to the right. This does not seem to be the case at the moment. When I'm in the second window, I press H and it goes right, it should go left, and it's the right in the leftmost window.

[dariooddenino]

I've been trying this branch today. A few notes:

1. It's not possible to shrink a buffer all the way down by increasing the size of another one. For example with | A | B | I can increase B width only up to a certain point, and after that I have to move to A and shrink it.
2. I think a reset to equal width command would be useful
3. It would be great to be able to get into a "resize mode" where one can just hold h/j/k/l to resize a window without having to repeat the whole A-w A-h/j/k/l command multiple times.
4. Minor thing, but I'm really not a fan of the alt-key combination for commands
5. Once some resizing has been done, opening new splits seem to be using weird window sizes

EDIT: I hope the diagram is clear enough! Changing the width with this setup works on window B, but not on window A

_   
A |     |
_ |  C  |
B |     |
_ |     |

[Jikstra]

I would love to see this merged, this is the only thing blocking me from using helix <3

[dgkf]

@Termina94 this has been idle for quite a while. Are you still planning to come back to it? If not, I think it's an important capability for any split-based text editor and would be willing to pick it up.

@pascalkuthe @the-mikedavis just tagging for visibility to get your input on what all would need to be included to get this across the finish line.

[claudemuller]

@Termina94 @the-mikedavis @dgkf Great work on this - I've switched over to Helix as a long time Vim user and am really enjoying it. I'm not sure what MR etiquette is here as I haven't really contributed to OSS yet, but I don't mind picking this up. I'm still a Rust n00b but have at least gotten the above pieces of feedback implemented (I thike 😅) and built locally.

[the-mikedavis]

See #8546, let's close this in favor of that new PR