Skip to content

fix(renderer): keep half the terminal when the flex reserve would take more - #702

Closed
eric-engberg wants to merge 1 commit into
sirmalloc:mainfrom
eric-engberg:fix/narrow-terminal-reserve
Closed

eric-engberg wants to merge 1 commit into
sirmalloc:mainfrom
eric-engberg:fix/narrow-terminal-reserve

Conversation

@eric-engberg

Copy link
Copy Markdown
Contributor

Relates to #498.

What

The width a flex mode reserves to the right of the status line now never takes more than half the terminal. Full width minus 40, and Full width until compact past its threshold, still reserve 40 columns from 80 columns up, so wide terminals are unchanged. On narrower terminals the status line keeps half the width:

Terminal Before After
120 columns 80 80
80 columns 40 40
79 columns 39 40
60 columns 20 30
41 columns 1 (.) 21
40 columns 0 (empty line) 20
30 columns 0 (empty line) 15

Full width always reserves 6 columns, so it only changes below 12 columns.

Why

#498 asks for a status line that works on a phone (the Moshi iOS app), where the terminal is about 40 columns wide. With the 40-column reserve that left almost nothing:

The reserve is there for Claude Code's auto-compact message, which can't fit beside anything on a terminal that narrow anyway, so giving it all of the width only costs the status line.

How

resolveEffectiveTerminalWidth in renderer.ts reserves min(reserve, floor(width / 2)) columns instead of the full reserve, for every flex mode, in the piped render and the TUI preview alike, so the preview still matches what Claude Code receives. The line can no longer get a width of 0 from a detected width, so a stale comment about that went too. docs/USAGE.md says how Full width minus 40 behaves below 80 columns.

This doesn't make layouts responsive, which the issue also asks about (for example dropping widgets on narrow terminals). It fixes the empty line and keeps half the width.

Demo

The same line piped with Full width minus 40 at 120 down to 30 columns, each render wrapped in [ ] so an empty one shows.

Powerline: before

Full minus 40 at 120 to 30 columns before the fix, Powerline mode

Powerline: after

Full minus 40 at 120 to 30 columns after the fix, Powerline mode

Plain: before

Full minus 40 at 120 to 30 columns before the fix, plain mode

Plain: after

Full minus 40 at 120 to 30 columns after the fix, plain mode

Testing

  • renderer-flex-width.test.ts:
    • New: every flex mode at 6 to 120 columns, both sides of Full until compact's threshold, piped and preview (20 cases), and Powerline with a flex separator at 30 to 120 columns.
    • These replace the two tests that pinned the empty line at 40 columns or fewer.
    • The tests that check the 40-column reserve itself now run at 100 columns with a longer line, since 50 columns is now in the capped range.
  • bun test: 3112 pass, 0 fail. bun run lint passes.
  • The changed test file under Node (Vitest): 28 of 28 pass.
  • Built CLI under Bun 1.4.2 and Node 26.10.0, Full width minus 40 at 120, 80, 60, 41, 40 and 30 columns, plain and Powerline: both runtimes give the same output, identical to main at 120 and 80 columns, and matching the table above at the narrower widths. runtime-check.sh against main with the baseline configs: same output, and the TUI opens and exits cleanly under both.

…e more

Full minus 40, and Full until compact past its threshold, reserve 40
columns for Claude Code's auto-compact message; Full reserves 6. On a
narrow terminal, such as a phone's or a split pane, that left almost
nothing: 41 columns truncated the line to a single ".", 60 columns
left 20, and since the zero-width fix 40 columns or fewer rendered an
empty line. Before that fix the line printed at full length and
wrapped instead.

Cap the reserve at half the terminal width. From 80 columns the full
40 still applies, so wide terminals are unchanged; below that the
status line keeps half the width: 40 columns now leave 20, 60 leave
30. Full's 6-column reserve is only capped under 12 columns. The TUI
preview uses the same widths, so it still matches what Claude Code
receives.
@sirmalloc

Copy link
Copy Markdown
Owner

I'm considering removing these settings entirely as the newer claude code builds keep the statusline full-width, and in theory set the COLUMNS env var when invoking it now. I haven't had time to test in depth or on other OSs, but in theory it should negate the need for these settings. Thoughts @eric-engberg ?

@eric-engberg

Copy link
Copy Markdown
Contributor Author

Makes sense to me. I checked what Claude Code 2.1.310 does: the status line command runs through the same runner as hooks, which sets COLUMNS and LINES from Claude Code's own terminal size. So ccstatusline could take its width from COLUMNS instead of walking up the process tree for a tty and running stty, which would also give Windows a width for the first time. I'd keep CCSTATUSLINE_WIDTH as the override, and the tty probe as the fallback for builds that don't set COLUMNS.

On dropping the reserve modes: if the line no longer shares its row with the auto-compact indicator, "full" is all that's left to choose, so the Terminal Width menu and compactThreshold could go, with old settings just ignored. I couldn't tell from the binary where the "% until auto-compact" indicator renders now, so that's worth a look in a long session before removing them. If they go, this PR is moot and I'll close it.

I can put up the COLUMNS change as a PR if you'd like.

@sirmalloc

Copy link
Copy Markdown
Owner

@eric-engberg Sure, if you want to put up the COLUMNS change and the full removal of the terminal width options I'm good with it. I think there might be another PR with the columns change, but I've gotten so many lately I'm still working my way through.

@eric-engberg

Copy link
Copy Markdown
Contributor Author

Done in #765: it takes the width from COLUMNS (with #612's commit as its first commit) and removes the Terminal Width options. Closing this one in favor of it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants