Appearance: Add a full-width option for the composer content

[Blackskyliner]

I did a quick manual search over the discussions, issues and PRs and did not find anything, so I might be the first one who's a bit annoyed by the following:

Currently the Composer window limits the content area to a fixed max-w-3xl.

This might be fine if only working an a standard MacBook display resolution as its almost a perfect fit - with a bit of room to breathe - but wastes possible usable space on 2k or 4k monitors even with sensible resolution or DPI scaling.

This also leads to always having the need to scroll horizontally on tables and outputs even though the screen real estate would be there to just display it.

A implementation seems to be straight forward. Make the max-w-3xl for the content of the Composer optionally disable-able within the appearance settings of the Application.

I get it that most applications also limit this width and designer vision and usability-bla-bla and in IMHO its stupid, let the user decide if he wants overly long lines or not esp. If he might be dealing with content output which naturally scales better on wider outputs.

To be more example driven: A simple request to my checkout "list me all open issues and prs which might be open and tldr me the actionable items" lead to a table which had 3 prosa intense columns which I needed to scroll because of the width limitation even though I had at least 2x the whitespace available to me for potential display of the full table w/o scrolling.

[Garfounkel]

Agreed, this is also a problem for me.

[Euino]

big issue for me also, thanks

[v1b3coder]

Also hit by this — on a 3440px-wide monitor the conversation and composer sit in a 768px column, so most of the chat pane is empty while wide output (tables, logs, diffs) still scrolls sideways inside that column. It is the main reason I don't use T3 Code on a large display.

There are two open PRs for this: #11594 (Comfortable / Wide / Full in Settings → Appearance) and #12785 (0–100% control in the thread header).

One note for whoever implements this: the cap is not only max-w-3xl in the timeline and composer containers. TIMELINE_CONTENT_MAX_WIDTH = 768 in MessagesTimeline.logic.ts also feeds resolveTimelineMinimapHasPersistentGutter and resolveTimelineMinimapHitStripWidth, which decide where the minimap hover strip may extend. With a full-width column those helpers still assume a 768px centered column, so at a 2560px viewport they compute a ~896px gutter and return the full 40px strip while the real gutter is 0. The strip then sits on top of the first ~40px of message text and swallows its pointer events, which is exactly what the comment above resolveTimelineMinimapHitStripWidth warns about. The chosen width needs to reach that helper too (or the helper should measure the lane element).

[piotrnowakowski]

Adding another data point: this is the biggest day-to-day usability issue I have with T3 Code on a wide monitor. The 48rem column leaves most of the window empty, while agent output with tables gets squeezed and clipped.

Any user-controllable width would solve it, whether the Comfortable/Wide/Full setting in #11594 or the header Width control in #12784 / #12785. Both PRs are open and waiting