Repository navigation
Splits do not redistribute space evenly when added #3839
|
This works perfectly in iterm2 but is clunky in ghostty. Adding new splits should divide the space evenly, not cut the focused one in half: Do a split, split twice: Iterm2:
Ghostty: |
Replies: 5 comments 1 reply
|
I'm not really sure that because another terminal does it that way Ghostty needs to do it too? personally I'd rather not have an existing split or window shrink down just because I'm adding another split or multiples and affecting all my existing sizes automatically. |
|
Yeah the question is really whether you are splitting the whole window or splitting the split. Perhaps a new command could redistribute space evenly across one axis for the current split's position. |
|
Mmm, rationale isn't "iterm2 does it therefore it's right". Iterm2 just has far more development and has implemented these refinements, it's obviously the right way to do it because 1 - the user wants 3 columns, almost always would want them even width, and not doing this means the user has to drag it every time to get the most commonly desired layout. Not wanting them even could be desired but that's an edge-case. The layout algorithm should target the most common expectation and only require an extra step to adjust for the less common one. If we already have an astoundingly good terminal like iterm2 we can look to it for inspiration... this project would likely not exists if iterm2 wasn't mac-only, it's already extremely good on macos and incredibly refined. It's the care and thought that went into these small details that makes it so good. |
I disagree. VT support and performance would've still motivated me to build this. I had already stopped using iTerm2 for Kitty for a number of years because I could type faster than the terminal could update, for example (Kitty was fast enough to prevent that). iTerm2 is a great terminal for many people, but for me it wouldn't have been enough. |
|
Converted to a discussion. Please read the rules |
|
This was a purposeful choice. I personally prefer if new splits only cause resize/reflow on the surface I'm splitting from. I was previously an iTerm2 user, and I didn't like this feature, so I changed it. However, I think introducing split equalization into the new split binding action is a fine non-default option. For that, I suggest we augment #2227 with this. |
This was a purposeful choice. I personally prefer if new splits only cause resize/reflow on the surface I'm splitting from. I was previously an iTerm2 user, and I didn't like this feature, so I changed it.
However, I think introducing split equalization into the new split binding action is a fine non-default option. For that, I suggest we augment #2227 with this.