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!

[sammcj]

Super keen for defined split layouts, especially in the age of having multiple coding agents and TUIs open every day!

[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 available offer similar (main + supporting panes) 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.

[willduncanphoto]

I stumbled into the Discord looking for a way to have a quick window split by default.

So here is my +1 for some sort of default layout controls.

I'd be stoked with just a quick-terminal-split = true though.

[mitchellh]

If you're a macOS user then #7634 will let you hack this in if you want. Not a long term solution but it does work.

[evanmoran]

@mitchellh I recently found Ghostty and I wanted to share an idea for a config option like this:

default-split-layout = <split-layout>

The challenge is how to define the split layouts so they are easy to understand but flexible enough for most people. After a bit of inspiration I came across this idea of naming it after the direction of the splits. I think it ended up quite nice.

Eastward: The split count in the west-to-east direction:

 _ _ 
|_|_|    eastward-1-1   (each dash adds a column eastward)

 _ _
| |_|    eastward-1-2 
|_|_|    

 _ _
| |_|    eastward-1-3    (this is kitty's tall layout)
| |_|  
|_|_|

 _ _
|_| |    eastward-2-1   
|_|_|  

 _ _
|_|_|    eastward-2-2   
|_|_|  

 _ _       
| |_|    eastward-2-3    
|-|_| 
|_|_|  

 _ _
|_| |    eastward-3-1    (this is kitty's tall layout - mirrored)
|_| |  
|_|_|

 _ _
|_| |    eastward-3-2    
|_|-|  
|_|_|

 _ _
|_|_|    eastward-3-3    
|_|_|  
|_|_|

This generalizes to more columns eastward, but I won't show all of them:

 _ _ _
|_|_|_|  eastward-1-1-1   (this is kitty's horizontal layout)

 _ _ _
| |_| |  eastward-1-2-1 
|_|_|_|

 _ _ _
| |_| |  eastward-1-3-2   (you get the idea!)
| |_|-| 
|_|_|_|

...      ...

Southward: The split count in the north-to-south direction:

 _ 
|_|      southward-1-1    (each dash adds a row)
|_|

 ___
|___|    southward-1-2      
|_|_|

 _____
|_____|  southward-1-3   (this is kitty fat)   
|_|_|_|

 ___
|_|_|    southward-2-1  
|___|

 ___
|_|_|    southward-2-2   
|_|_|

 _____
|__|__|  southward-2-3 
|_|_|_|
 
 _____
|_|_|_|  southward-3-1   (this is kitty's fat layout - mirrored)
|_____|     

 _____
|_|_|_|  southward-3-2   
|__|__|       

 _____
|_|_|_|  southward-3-3   (this is kitty's grid layout)
|_|_|_|       

This generalizes to more rows southward, but I won't show all of them:

 _ 
|_|      southward-1-1-1    (this is kitty's vertical layout)
|_|
|_|

 ___
|___|    southward-1-2-1      
|_|_|
|___|

 _____
|_____|  southward-1-3-2   (you get the idea!)      
|_|_|_|
|__|__|

...      ...
   

Curious if this layout naming scheme makes sense to you. I tried several naming approaches: left-to-right-1-2-3, east-to-west-1-2-3, east1-mide2-west3,e1-m2-w3, etc, but eastward/southward seemed the simpliest of those choices.

To start I'd probably hardcode layouts for up to 4-4-4 for both eastward and southward directions (64 each), so easy to configure with a single string constant and significantly more powerful than other terminals. Hope that helps!

[sammcj]

Has anyone found a workaround for Ghostty not supporting split layout profiles / defaults?

Coming from iTerm where I always defaulted to a 2x2 grid it would be great to have this in Ghostty

[jnines]

Has anyone found a workaround for Ghostty not support split layout profiles / defaults?

Coming from iTerm where I always defaulted to a 2x2 grid it would be great to have this in Ghostty

At this point, unless there are changes I just didn't read about, it seems you'll have to rely on outside tools one way or the other.

Either shell scripting with xdotool/ydotool/etc, or tmux (or similar), either with shell scripting yourself or using rmuxinator/tmuxinator/etc.

[alexcraviotto]

What tools?

[evanmoran]

I think a setting that restores the previous layout on launch would be enough for a lot of people. The more I see how I use Ghosty the more I realize the layout I like isn't easy to specify. Restore would be plenty for me though, as it doesn't seem to change much once I found what worked.

[sammcj]

Not for me, in iterm and others I start the day with a 4 pane split which evolves throughout the day until I close call panes and know that when I trigger the term hot key again - I'll get my trusty 4 pane split back.

[mattszein]

Hey, I believe a good layout configuration system could be very useful. Ghostty already supports tabs and splits and layout feature could be a game-changer! I currently using a script to open my default layout: tab 1 with neovim, tab 2 with servers and logs with a horizontal split and lazydocker running in one of them, and 3rd tab for git, lazygit and other things. My script uses ydotool to send keys and open a new tab, or a split, or type a command.
I think zellij has a really good layout schema. For example:

layout {
  tab name="code" {
    pane {
      command "nvim"
    }
  }

  tab name="dev" {
    pane split_direction="vertical" {
      pane
      pane split_direction="horizontal"{
        pane {
          command "lazydocker"
        }
        pane
      }
    }
  }
  tab name="git" {
    pane split_direction="vertical" {
      pane
      pane {
        command "lazygit"
      }
    }
  }
}

ghostty could have a default layout with one tab, and could be opened with a specific layout like: ghostty --layout dev.layout or ghostty -l dev.layout

[classicrob]

Personally, I want this so I can give Claude Code more control of my experience - I want it to be able to open splits to show me images or text files as we're chatting.

[rhodes-b]

That would be #2353 this is to have ghostty start with a specific layout / other posts here say it determines how new splits are made

Nothing about letting a app remote control creation

[evanmoran]

After more thinking I think the solution must mirror the UI functionality of selecting regions and choosing horizontal or vertical splits. It turns out splitting is easy, so the real issue is syntactically choosing the next region to split.

To this end I propose a space separated list that chooses the coordinates (25-50), horizontal split (h) or vertical split (v).

For example:

“v 25-50 hhh 75-25 vv”

This means start with initial region and do one vertical split (v)

Then select region at 25%-50% coordinates and do three horizontal splits (hhh)

Finally select region at 75%-25% coordinates and do two vertical splits (vv)

The list can be any length handling all layouts, and I think most examples would be about 10-20 characters for most people.

What do you all think?

[phillip-haydon]

Sounds confusing. Whatever solution you do can you just add a “save current layout”

[Traviskn]

I believe that the window save state option supports this: https://ghostty.org/docs/config/reference#window-save-state
I add window-save-state = always to my Ghostty config

[evanmoran]

Yes, it should definitely have a way to save the layout.

As for confusion: there aren’t many good ways to indicate which region. Either you use region index or use a coordinate to find it by position.

Region is hard because the splits add more regions so it’s hard to guess which is which.

Coordinates are hard because if you do pixels then your layout might come out differently based on the initial window size (hence choosing percents to be constant).

So it comes down to two choices. Percent coordinates:

v 25-50 hhh 75-25 vv

Or region indexes, which will feel a bit arbitrary but look simpler:

v 2 hhh 4 vv

Clearly, the second is easier to code and both require a bit of trial and error to get right so I don’t have a strong preference :) What I am 100% sure of is this fully expresses all layouts, and that that is rare enough other terminals can not do it.

[arongun]

+1 for this! I spend most of my day in Ghostty with Claude Code and usually end up with the same layout every time. Right now I'm manually splitting every session which gets old fast.

Honestly, even just a default-layout config that restores a basic split setup on launch would cover 90% of my use case. Something like zellij's declarative approach with per-pane commands would be the dream though - being able to ghostty --layout dev and have everything ready to go would be huge.

Would love to see this land in any form.

[Traviskn]

I believe that the window save state option supports this: https://ghostty.org/docs/config/reference#window-save-state
I've added window-save-state = always to my Ghostty config, and if I add a split, quit Ghostty, then re-open it, it opens with the same splits I had before

[sammcj]

That just reopens all your previous session layouts not a saved or standard defined layout

[phillip-haydon]

If there is the ability to open the state from a previous session then why can’t a “save layout” be implemented and no need for complicated config. Just lay it out. Save it. And open that layout on request…

[rhodes-b]

Because then ghostty has to do the work in the case of window save state macos does basically everything ghostty just has to tell macos save my windows when I close. In the case you are describing ghostty has to know how to restore a state from some kind of serialized format which at that point could just be a configuration format

ghostty/macos/Sources/App/macOS/AppDelegate.swift

Line 864 in c1207af

case "always": UserDefaults.standard.setValue(true, forKey: "NSQuitAlwaysKeepsWindows")

[rhodes-b]

For all the recent comments in this thread +1 here is my usecase is not helpful all it does it send a email to everyone subscribed (which at the point of this comment is 19 people). Its also not helpful to ping maintainers its not going to get this feature added any quicker. Ghostty is FOSS where maintainers work on what they want to work on and some of them simply just ignore all emails from github (by sending it to their trash or spam folders)

Github discussions have a arrow that show you want this feature it even bumps the thread to the top of the discussions for recent activity and it doesn't send a email to everyone, use that instead if you don't have an idea of how the configuration should look or some detail that may be useful (like an example of how kitty does it)

window-save-state is not the solution for this
1 it currently does not work on linux (that is subject to change in the future with a new GTK api we will see)
2 the user still has to manually make a configuration then make sure to always close the window in that configuration if the app crashes unexpectedly then it might not work etc, this feature request is not asking for that even though it may cover some peoples usecases currently on macos

approach with per-pane commands would be the dream though

that is a entirely separate discussion #2353 which honestly might cover creating layouts programmatically in the long term as its more generic. Zellij example was already listed above #2480 (comment)

the Zellij configuration style is highly unlikely to make its way into ghostty as it completely deviates from the current configuration syntax of
key = value entries so please take that into consideration on making a suggestion is how would it fit into the current configuration style.

This discussion also has some comments on saving a current layout, to be clear from my perspective that is a entirely separate feature request which relies on the ability to even define layouts in the first place as such it should be its own discussion

[evanmoran]

Hi everyone,

After quite of bit of thought, here's my updated proposal for the config format. Much appreciate @rhodes-b for clarifying the focus of this thread. Please upvote / downvote if you like the proposal.

I'm happy to provide an initial PR if people like the direction.

Additionally, this proposal is for a simple config option like layout=<layout string> to set the initial layout for new windows. As it was suggested, we can leave future functionality to save the current layout or switch quickly between multiple layouts, etc, to other discussions.

Layout String

Example possible config:

layout = v 2 h 2.1 vv

The basic concept is the layout string alternates between split commands (v, h, vv, hh, etc.) and region selection commands (2, 2.1, 2.1.2, etc) to describe how the layout is made.

Each letter is one cut, where v makes 2 vertical splits, vv makes 3 splits, and so on. After a split you choose the region number to subdivide it further. Children inherit their parent's region id so splitting region 2 produces 2.1, 2.2, etc.

That's basically it. This walkthrough below shows an example step by step. And after that the I've listed a few common layouts to show what most's configs would like.

I believe this can express 100% of possible layouts (much better than my first proposal). And the region naming (2, 2.1, etc) was inspired to mimic how BSP trees select the next partition (https://en.wikipedia.org/wiki/Binary_space_partitioning).

Walkthrough: "v 2 h 2.1 vv"

"v" Split once vertically into 1, 2

    ┌────────┬────────┐
    │        │        │
    │   1    │   2    │
    │        │        │
    └────────┴────────┘

"v 2 h" Select 2, split once horizontally into 2.1, 2.2

    ┌────────┬────────┐
    │        │  2.1   │
    │   1    ├────────┤
    │        │  2.2   │
    └────────┴────────┘

"v 2 h 2.1 vv" Select 2.1, split twice vertically into 2.1.1, 2.1.2, 2.1.3

    ┌────────┬─────┬─────┬─────┐
    │        │     │     │     │
    │   1    │2.1.1│2.1.2│2.1.3│
    │        │     │     │     │
    │        ├─────┴─────┴─────┤
    │        │       2.2       │
    └────────┴─────────────────┘

Common Layouts

Two columns — v

    ┌──────────┬──────────┐
    │          │          │
    │    1     │    2     │
    │          │          │
    └──────────┴──────────┘

Three columns — vv

    ┌───────┬───────┬───────┐
    │       │       │       │
    │   1   │   2   │   3   │
    │       │       │       │
    └───────┴───────┴───────┘

Two rows — h

    ┌─────────────────────┐
    │          1          │
    ├─────────────────────┤
    │          2          │
    └─────────────────────┘

Three rows — hh

    ┌─────────────────────┐
    │          1          │
    ├─────────────────────┤
    │          2          │
    ├─────────────────────┤
    │          3          │
    └─────────────────────┘

Two stack right — v 2 h

    ┌──────────┬──────────┐
    │          │   2.1    │
    │    1     ├──────────┤
    │          │   2.2    │
    └──────────┴──────────┘

Three stack right — v 2 hh

    ┌──────────┬──────────┐
    │          │   2.1    │
    │          ├──────────┤
    │    1     │   2.2    │
    │          ├──────────┤
    │          │   2.3    │
    └──────────┴──────────┘

Quad grid — v 1 h 2 h

    ┌──────────┬──────────┐
    │   1.1    │   2.1    │
    ├──────────┼──────────┤
    │   1.2    │   2.2    │
    └──────────┴──────────┘

Three column bottom — h 2 vv

    ┌─────────────────────┐
    │          1          │
    ├───────┬───────┬─────┤
    │  2.1  │  2.2  │ 2.3 │
    └───────┴───────┴─────┘

Center stage — vv 2 h

    ┌───────┬───────┬───────┐
    │       │  2.1  │       │
    │   1   ├───────┤   3   │
    │       │  2.2  │       │
    └───────┴───────┴───────┘   

[8bittts]

i mean, can't you do this now and have it just save the splits natively so when you come back it's there? or you're wanting these pre-defined views that you could auto-magically apply?

[phillip-haydon]

i mean, can't you do this now and have it just save the splits natively so when you come back it's there? or you're wanting these pre-defined views that you could auto-magically apply?

I want to have a couple of named layouts I can pick between (basically depends on if I’m docked at my desk or sitting on the couch which I have 2x4 or 2x3 split)

One of the main issues with the proposals is its only defining layout. I can’t remember what I used on windows but the layout allowed me to also define the commands to run in each pane so I could set the panes to different folders when it opened. That’s less of an issue but still would like have a defined layout.

[sammcj]

No you can't save a layout now, it can only save whatever the state of your terminals are when you exit. So as you add, remove and resize terminals throughout the day your desired layout is lost.

[evanmoran]

Totally agree that grids like 2x3 and 2x4 should be easy to express. That's exactly what this proposal enables:

2x3 — `h 1 vv 2 vv`
    ┌───────┬───────┬───────┐
    │  1.1  │  1.2  │  1.3  │
    ├───────┼───────┼───────┤
    │  2.1  │  2.2  │  2.3  │
    └───────┴───────┴───────┘

2x4 — `h 1 vvv 2 vvv`
    ┌─────┬─────┬─────┬─────┐
    │ 1.1 │ 1.2 │ 1.3 │ 1.4 │
    ├─────┼─────┼─────┼─────┤
    │ 2.1 │ 2.2 │ 2.3 │ 2.4 │
    └─────┴─────┴─────┴─────┘

The real power is in a layout like Kitty "splits" layout:
(https://sw.kovidgoyal.net/kitty/layouts/)

In this layout system splits would look like v 2 hh 2.2 v

And here's step by step why this works:

`v` Split vertically → 1, 2
    ┌──────────────┬──────────────┐
    │              │              │
    │      1       │      2       │
    │              │              │
    └──────────────┴──────────────┘

`v 2 hh` Select 2, split twice horizontally → 2.1, 2.2, 2.3
    ┌──────────────┬──────────────┐
    │              │     2.1      │
    │              ├──────────────┤
    │      1       │     2.2      │
    │              ├──────────────┤
    │              │     2.3      │
    └──────────────┴──────────────┘

`v 2 hh 2.2 v` Select 2.2, split vertically → 2.2.1, 2.2.2
    ┌──────────────┬──────────────┐
    │              │     2.1      │
    │              ├───────┬──────┤
    │      1       │ 2.2.1 │2.2.2 │
    │              ├───────┴──────┤
    │              │     2.3      │
    └──────────────┴──────────────┘

Once you can describe any layout as a string, the rest is easy: a config setting for the default layout, keybindings to switch between layouts, and so on.

[8bittts]

i hacked together a cmd + option + 1-9 to create a proof of concept (on macOS). cmd + option + 5 creates 4 splits auto-magically, etc. i'm going to work on a few of these other versions too. is this what you wanted? video here and the current 10 options here.

[phillip-haydon]

Thats cool. I found the one I was thinking about. It's `ConEmu'
https://conemu.github.io/en/NewConsole.html#syntax

You could define paths or commands to run with the new console.

-new_console:d:”C:/projects/project-a”

But this is far less important to me than just having a layout defined. I like the proposal for 2x3 / 2x4

[mattszein]

I think the split layout is concise. However, I believe this "Layout" system is incomplete, i know the title is about 'split layout' but a real-world workflow usually requires:

• Context: What commands are running in those splits?
• Organization: Multiple tabs for different parts of the project (e.g., Editor, Logs, Services).

I suggest extending the syntax by introducing a tab (t) and attribute blocks ([]).
t: Creates a new tab. All subsequent split commands apply to this tab until the next t.
[...]: An optional attribute block that attaches to the preceding region or tab. It can contain cmd (command), title, or cwd.

Example Syntax

layout = t [title="Backend"] v 1 [cmd="nvim"] 2 h 2.1 [cmd="cargo watch"] 2.2 t [title="Infrastructure"] [cmd="docker compose up"]

Compatibility: If you don't use t or [], the syntax remains identical to the original proposal.

[8bittts]

i added a manual viewer with shortcuts:

[evanmoran]

@mattszein makes a great point that per region you want different cmds and per tab you'd want different titles. I'd even go further and mention that I really like different background colors per region as well. This is actually what my main layout does today. You could call it "Eastward 1-1-3", and – for those playing along at home 😊 – is the split layout string vv 3 hh:

That said, embedding commands and titles directly into the layout string might be more than we need for an initial version. The richer syntax is clean and fully compatible, so it could layer on naturally in the next version.

To make this concrete, I’d propose two configuration settings:

# Default layout
layout = vv 3 hh

# Keybind to change the layout
keybind = cmd+1=set_layout: vv 3 hh

P.S. @8bittts, the UI and swapping video look fantastic. Curious if the split layout string direction feels flexible enough vs predefined layouts to you? I tried several other syntaxes first (region indexes, coordinate-based strings), but the dot-as-split naming felt easier to reason about. Curious your thoughts!

[8bittts]

what's nice is you can just do your micro adjustments and that'll save when you close. so, yeah. it really does.