Font size changes don't resize window, interacts badly with window-step-resize

[lilyball]

When I use the Increase/Decrease/Reset Font Size actions the font size changes but the window doesn't resize. This is very surprising. Both Terminal.app and iTerm resize the window, and my natural expectation is the window should resize to preserve the cell grid because font size changes shouldn't cause layout changes.

I filed an issue on this and was told this behavior is intentional, and that surprised me. Why should the font size change layout? This isn't a text editor with soft wrapping, it's a terminal where exact layout can matter a lot. If I've set the window to a specific row/column count, it should stay at that count until I tell it otherwise. Many programs don't handle resizing well while running (e.g. if I'm reading a man page it lays out text to match my terminal width, but it doesn't relayout on resize, so if I want to increase font size for readability I need to quit and re-run the man command). Or maybe I'm in a shared zellij session and increasing font size suddenly caused my code pairing partner's zellij pane to shrink.

Beyond the arguments for why the behavior should be changed, the current behavior interacts badly with window-step-resize. The point of window-step-resize is to keep the window aligned with the cell grid so there's no extra padding. But when I change font size and the window doesn't resize, the window loses its alignment with the cell grid and this causes additional padding. And because window-step-resize works by just forcing resizing to work in increments of the cell size rather than snapping to the cell grid, there's no way to resize my window to get rid of that padding.

Here's some steps to try to see this:

1. Ensure window-step-resize is on
2. Increase font size a bunch
3. Resize the window slightly
4. Reset font size
5. Try to resize the window back to its original size

Unless you're very lucky, the window resizing is now operating on a different grid than before and you cannot match the original pixel dimensions of the window, which also means you're stuck with the extra padding, unless you repeat these steps in reverse.

The window-step-resize issue could be worked around by either snapping the window back to the cell grid the moment the user tries to resize, or snapping it to the cell grid when changing font size (but having the window pixel dimensions waver slightly as the font size changes would be weird), but really this shouldn't happen at all because font size changes should simply resize the window to preserve the cell layout.

[lilyball]

Oh another quirk of the current behavior: if I set window-padding-balance = true, then changing the font size also changes the left/top padding so all of the text jumps around oddly.

[mitchellh]

I filed #2659 and was told this behavior is intentional, and that surprised me. Why should the font size change layout? This isn't a text editor with soft wrapping, it's a terminal where exact layout can matter a lot.

The decision to make it intentional was mine. My previous terminal was Kitty and it behaved this way and I liked this behavior. Other terminals also behave this way (Alacritty another). I don't think there's any consensus on correctness here, I think it's a matter of personal taste. In my opinion, the window changing size is worse, more software handles layout just fine on resize than not, etc. But, I can see the reverse argument too.

I will not be changing this behavior, but I am open to introducing a configuration or keybind that behaves the way you request. Because, as I said, I can see the argument for it, and I'm not sure I've ever seen a terminal make this configurable before. A keybinding would be particularly interesting because then you can have both at the same time (for situations you're using a program that doesn't relayout well).

I think there is also merit that this behavior should change in the context of certain other configurations such as window-step-resize. Namely, if that is true, we should probably default to font changes also changing the window size. I don't think that'd be surprising and I'm supportive of that. But supporting window size changes on font size change is probably the first thing that should be done.

To move that forward, if there is interest, I think some thought needs to go into how this would work with our apprt system. Presently, font change is purely libghostty and apprts don't even know it happens.

[lilyball]

I would be ok with the idea that window-step-resize controls the behavior here, since window-step-resize is basically the "I want my window size to sync to the cell grid" option, and what I'm asking for here is for the window size to simply reflect the correct size for my cell grid.

Also to note, if I use a configuration change that switches fonts, that too is a spot where the window size needs to adjust itself for the new cell grid when using window-step-resize.

[mitchellh]

It really needs to happen I think for any font property change that could affect the grid. We luckily have a hashed value that can be used to detect this already (SharedFontGridSet.Key) since that is how we dedupe memory usage across terminals that share identical font settings (this was a source of extreme memory bloat once upon a time).

To be explicit: there are many more things that affect the grid that are runtime-changeable such as adjust-cell-width and so on. And there could be even more in the future. These are all tied to the font grid key I think because they affect things like sprite rendering (implemented in the font system). Confirmation needed.

So I think what we need to do is detect anytime the font grid key changes, recalculate a desired screen size, and ask the apprt to go to that size. If the apprt fails or doesn't support going to that size, we can fallback to resizing the grid.

[seanh]

I came here to report the same issue, and found this discussion.

👍 to having the behaviour change when window-step-resize is on. window-step-resize currently breaks when you change the font size and I don't think there's any solution to that other than changing the window size when the font size changes, at least when window-step-resize is on.

---

I use window-step-resize because I don't want a random amount of padding at the edges of the window because I think that looks bad, I want things drawn in the terminal with a background color (like status bars etc) to go right to the edge of the window. Currently window-step-resize achieves this beautifully but changing the font size breaks it.

Also second @lilyball's point that keeping the number of rows and columns constant can be desirable to avoid messing up what's currently displayed in the terminal.

I do agree that this may be one of those personal taste things about terminals, where different users just have different preferences and there's no one behavior that can satisfy everyone. So I think tying this to window-step-resize makes sense.

[JakeWharton]

Related #2946