Ability to define split layouts

[scnewma]

One of the features that I cannot live without with tmux is it's layout feature. This feature allows for panes to be automatically laid out with a given width/height.

AFAICT, I cannot reproduce this behavior with Ghostty, but would really love it so that I could use ghostty without tmux.

---

To provide additional context for my workflow, I use tmux's main-vertical layout, when I add a new pane I automatically target bottom-left. This allows my new splits to always be outside of the "main" pane, with the height of the new panes always being evenly split (I accomplish this by "reselecting" the layout via hooks).

[mitchellh]

I converted this to a discussion to gather some more feedback and design the configuration style and so on. I'm supportive of this feature but I think it needs to be slightly better defined in the context of Ghostty before we go off and make an issue. You didn't do anything wrong, just noting my decision making process. Thanks!

[scnewma]

To kickstart the discussion, I'd personally like to be able to have something like the following:

A new action named select_layout that takes a layout as an argument:

• main - Top-pane main, supporting panes at bottom.
• main_vertical - Left-pane main, supporting panes on right.
• main_mirrored - Bottom-pane main, supporting panes at top.
• main_vertical_mirrored - Right-pane main, supporting panes on left.

I'd also like to see some configurations for adjusting the width/height. These would be a # of columns or a % of the width/height:

• layout_main_pane_height = <HEIGHT>
• layout_main_pane_width = <WIDTH>

This is all largely based off of how tmux handles this. I could also see the height/width being arguments on the select_layout action. I don't have strong opinions.

[qbedard]

For examples from other applications that support this type of tiling behavior:

• Amethyst's layouts are very similar to @scnewma's suggestions.
• bspwm's binary space partitioning is one of many possible layout strategies.
• Wayland's compositors are an abstraction layer above the layouts, but many of those offered offer similar (main + supporting panges) options. It also has some other options, like scrollable tiling.
• xmonad's layouts inspired Amethyst's, and are similar.

I agree with @scnewma's suggestions, as the basic idea is one main pane and N supporting panes, with the ability to swap between layouts with a command and resize the main size. It would also be nice to see middle main pane (supporting on sides) and binary space partitioning.

[chrede88]

Coming from kitty, I like the idea of setting a preferred split-pane layout. This way, I can bind a single keybind to create a new split (and I know where it's going to land). I personally use the tall layout in kitty (but having some options is nice). Link to kitty docs: https://sw.kovidgoyal.net/kitty/overview/#layouts

[bvergnaud]

I'd also love a similar feature. Coming from kitty, that's one of the rare "missing" features for me.

Personally, I tend to use 3 layouts: grid (balanced grid with each pane taking up roughly the same space), vertical and horizontal (all panes in a column/row, balanced in size).

To get there, I see 2 problems with ghostty.

---

First, the current split strategy systematically creates a new level of depth in the tree. For instance, split right twice in a new window, you get [50%[25%|25%]] because the second pane was implicitly turned from a leaf node into a branch node with two leaf nodes under it.

Some people want that, that's fine. But an equally valid choice would be to create new levels only as needed. In the same "split right twice" example, one could expect to get [33%|33%|33%] instead.
The tiling window managers i3 & sway are good examples of that. By default, splitting balances the space allocation, and it only creates new containers when you switch direction or force its hand with some key bind.

I believe this change alone would make kitty's vertical/horizontal/tall/fat layouts and most of the main+support models described above trivial to do "by hand".
I'm also pretty sure that it's necessary for the next part, because some layouts require balanced splits.

---

Regarding more complex layouts like grid, the issue is that I don't think you can't do them trivially by hand. Even with the first problem above solved to eliminate the need for the equalize_splits action. You still have to make conscious and careful choices about where you're splitting from, in what direction, and it can take quite a lot of key binds and key presses to get the end result you want.

The only way I can think of to make it trivial is to have the terminal define the rules and logic of each layout ahead of time, and not have users recreate them by hand every time.

In that regard, I think kitty has a decent approach. There's a splits layout which is essentially free hand split by the user, exactly as we have now in ghostty. All the other layouts are defined by kitty's codebase, with some minor resizing / mirroring options in some cases.

And in terms of configuration / user interaction, it works really nicely. At least I don't see how to do much simpler or more efficient for the user:

• In your config file, you list which layouts you like to use, in order of preference.
• Each new window starts in the first layout you chose, and a single key bind cycles through these layouts in order.

For reference: https://sw.kovidgoyal.net/kitty/layouts/

[ck3mp3r]

I've written a utility that manages specific sessions and layouts in tmux, currently working on a "driver" for zellij. Not sure yet how useful it will be but I am using the process of adding this functionality to refactor the codebase. Long story short, I'd love to be able to script ghostty to allow native layouts without needing a multiplexer like tmux or zellij.

[jjt]

another user of kitty's tall layout here, would love something similar in ghostty

also related would be a way to define a "main" split and be able to move the current focused split into "main" with an action like swap_with_main

"main" split contains A
while B,C,D are stacked on side

C is currently focused
 ┌───────────┬─────┐              
 │           │     │              
 │           │  B  │              
 │           │     │              
 │           ├─────┤              
 │           │┌───┐│              
 │     A     ││ C ││              
 │           │└───┘│              
 │           ├─────┤              
 │           │     │              
 │           │  D  │              
 │           │     │              
 └───────────┴─────┘              
                                  
 running `swap_with_main` action  
 results in this, focus stays with C
                                  
 ┌───────────┬─────┐              
 │┌─────────┐│     │              
 ││         ││  B  │              
 ││         ││     │              
 ││         │├─────┤              
 ││         ││     │              
 ││    C    ││  A  │              
 ││         ││     │              
 ││         │├─────┤              
 ││         ││     │              
 ││         ││  D  │              
 │└─────────┘│     │              
 └───────────┴─────┘              

[jnines]

I do something somewhat similar with Ghostty(previously Alacritty)/Tmux/Tmuxinator. It allows for preconfigured layouts/commands.

---
# name: Multi
name: Multi <%= rand(65536) %>
startup_pane: 0
windows:
  - ✖:
      layout: 92fd,168x42,0,0{83x42,0,0[83x13,0,0,0,83x13,0,14,1,83x14,0,28,2],84x42,84,0[84x13,84,0,3,84x13,84,14,4,84x14,84,28,5]}
      panes:
        -  #  local
        -  #  local
        - ash:
            - ssh ash
        - lg:
            - ssh deskg
        - na:
            - ssh lapn
        - dn:
            - ssh kandarian

Would be great to have something like this in Ghostty as I'm mainly using it for the layout and broadcasting commands(which can sort of be done with all:), less so for persistence (which I could still use tmux for).

I'm guessing however that it would require a lot of work. Technically I can do something similar with ydotool(xdotool) but it's incredibly janky.

[ck3mp3r]

I've written a session and layout manager for tmux and I've also added experimental zellij support. You can specify pretty accurate layout configurations that go beyond what tmux offers out of the box. I borrowed the flex-box analogy from front end layout engines.

It would be great to also add Ghostty as another potential multiplexer into the mix... So I'm all for a programatic interface to managing tabs and panes within Ghostty.