feat(tui): make the sidebar width configurable - #46117
Open
iceteaSA wants to merge 1 commit into
Open
Conversation
The sidebar width was hardcoded to 42 in two independent places. It is now a single clamped source fed by the sidebar_width config key. The clamp enforces a minimum of 20 for legibility, a terminal-width-derived maximum of terminal width minus 40 to preserve main content, and a hard cap of 100.
1 task
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue for this PR
Closes #35513
Type of change
What does this PR do?
Adds a
sidebar_widthkey to the TUI config.42stays the default, so nothing changes unless you set it.The width was hardcoded in two places that had to agree:
<box width={42}>in the sidebar component, and the session route's content math (dimensions().width - (sidebarVisible() ? 42 : 0) - 4). Both now read onesidebarWidth()memo. Collapsing that duplication is half the value here — two literals that must stay in sync is where the next layout bug was going to come from.The resolved width is clamped to
max(20, min(configured, terminalWidth - 40, 100)):terminalWidth - 40— the main pane keeps at least 40 columnsThe clamp runs on read rather than only at config load, so shrinking the terminal degrades the sidebar instead of squeezing the main pane. The outer
max(20, …)matters on small terminals where the bounds invert (at 55 columns,terminalWidth - 40is 15, under the floor) — the minimum wins there and the function stays total. That case is unreachable today since terminals at or below 120 columns render the sidebar as an overlay, but the function shouldn't depend on that.sidebar_widthisSchema.Int.check(Schema.isGreaterThan(0)), matchingleader_timeoutand the prompt size fields, so a fractional or negative value is a config error rather than a fractional column count.This is deliberately just the config key. A follow-up adds a drag rail, a collapse state, and runtime persistence — kept separate so this part is reviewable on its own.
How did you verify your code works?
packages/tui: 199 pass / 0 fail; 6 focused tests on the clamp covering the floor, the terminal-content cap, the hard cap, the inverted-bounds case, and the defaultbun typecheckclean inpackages/tuiandpackages/opencodeclampSidebarWidthreturn the raw configured value fails 4 of the 6 focused testsScreenshots / recordings
No visual change at the default width.
Checklist