Toggling split zoom results in redraws occurring inconsistently

[ricardonunez-io]

Hi there! Love Ghostty, use it everyday, but I've been running into this issue unfortunately where toggling split-zoom on a terminal pane (using the Ghostty native command super+shift+enter) results in the redrawn content being off.

It works both ways. Included a video of going from half-width to full-width but also occurs when going from full-width to half width especially with JSON logs. The redrawn content is cut off weirdly, spaces are added weirdly, or the width is set incorrectly.

In the video, I'm referring to the logs underneath the standard full-width timing Docker logs, i.e. not the fact that the logs don't resize (it shouldn't), but the fact that some of the logs flow into the previous line

This also manifests itself when copy/pasting the content, the spaces exist also when pasting, which is typically most visible when copy/pasting JSON, since it gets cut off and mis-formatted.

compressed_split-zoom-bug.mp4

Running on macOS 15.3.2 and Ghostty e07b6fdf

Seems like the redraw might be occurring too quickly perhaps? Thank you!

[00-kat]

where toggling split-zoom on a terminal pane

Does this also manifest when resizing the window? That may help narrow it down.

[ricardonunez-io]

Hi @00-kat! So sorry, never saw this question, but unfortunately, it does.

Here's an example from a test run I just ran where originally, the pane was at half screen but toggled to full screen, then split toggle zoom was not applied (original sizing, how stdout was when the tests ran), then the window was resized from full screen to non-full screen to smaller, and then resized even smaller.

Towards the middle, you can see there's spaces applied to the __test__/utils/... line, and on full screen, even more.

Full-screen after toggling split-zoom

Original dimensions, no changes made

Ghostty set from macOS full-screen to non-full-screen

Ghostty window at even smaller dimensions than non-full-screen

[mitchellh]

Ah, hah.

This is probably a program issue (in this case, Docker?). I've seen this before and I've also done this before as a CLI program author in the past.

The program looks like it might be using spaces to wrap to the second line rather than a hard line break (\n). Ghostty will reflow text that soft wrapped because that's what is being signaled to it. There isn't really anything Ghostty can do about this, the program running needs to be explicit in where it wants line breaks and should avoid soft wrapping. That's the only way forward.

If you want me to look further into it being a Ghostty issue, recording an asciinema of the output and sharing the cast file with me (this thread) will work. I can then tell you exactly what sequences its sending.