feat(desktop): loosen right-rail preview width caps (38rem → 72rem) - #40511
Open
liuhao1024 wants to merge 2 commits into
Open
feat(desktop): loosen right-rail preview width caps (38rem → 72rem)#40511liuhao1024 wants to merge 2 commits into
liuhao1024 wants to merge 2 commits into
Conversation
Increase the preview pane's intrinsic width cap from 32rem to 64rem and the hard max from 38rem to 72rem. Also remove the max-w-3xl (48rem) constraint on the MarkdownPreview wrapper so rendered content can use the full available width. Wide content — code listings, tables, Mermaid gantt/sequenceDiagrams, and CSV/log previews — currently wraps or scrolls horizontally even on large monitors because the rail caps out at 38rem. The default opening width is unchanged; users still drag the divider to expand. Fixes NousResearch#40494
alt-glitch
added
type/feature
3 tasks
teknium1
reviewed
Jul 14, 2026
teknium1
left a comment
teknium1
left a comment
Contributor
There was a problem hiding this comment.
Thanks for tracing all three active width constraints. Current main confirms that apps/desktop/src/app/desktop-controller.tsx:1161-1170 passes the preview constants into the resizable Pane, and rendered Markdown still uses the independent max-w-3xl wrapper at apps/desktop/src/app/chat/right-rail/preview-file.tsx:332.
Problems
- The linked report was revised after this patch: #40494's June 7 follow-ups say the proposed 72rem/64rem ceilings were still cramped and explicitly replace them with 96rem/80rem. This diff keeps the superseded 72rem/64rem values in
apps/desktop/src/app/chat/right-rail/preview.tsx.
Suggested changes
- When salvaging, align both constants with the revised issue target, or record a maintainer decision for the lower ceilings. The
max-w-noneMarkdown change should remain because it removes a separate live 48rem content cap.
Automated hermes-sweeper review.
|
|
||
| export const PREVIEW_RAIL_MIN_WIDTH = '18rem' | ||
| export const PREVIEW_RAIL_MAX_WIDTH = '38rem' | ||
| export const PREVIEW_RAIL_MAX_WIDTH = '72rem' |
Contributor
There was a problem hiding this comment.
The linked issue was updated after this proposal: its reporter says 72rem/64rem remained cramped and explicitly requests 96rem/80rem. Please align both caps with that revised target, or document why the lower limits remain appropriate.
teknium1
added
sweeper:risk-compatibility
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
3 participants
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.
Summary
Loosen the right-rail preview pane's width caps so wide content (code listings, tables, Mermaid diagrams, CSV/log previews) can use the full available horizontal space on large monitors.
Changes (2 files, 3 lines):
preview.tsxPREVIEW_RAIL_MAX_WIDTH:38rem→72rempreview.tsxINTRINSICclamp upper bound:32rem→64rempreview-file.tsxMarkdownPreviewwrapper:max-w-3xl(48rem) →max-w-noneMotivation
The preview pane currently caps at ~38rem even on wide monitors (27"+ / 16:10). Content wraps or scrolls horizontally despite abundant screen real estate. This is especially noticeable with:
gantt,sequenceDiagram) that are often wider than 38rem.mdartifact, user reviews it in the rail alongside chatThe default opening width is unchanged — users still drag the divider to expand. The cap just no longer kicks in early.
Before / After
max-w-3xl)max-w-none)Testing
main @ 56236b16ePREVIEW_RAIL_PANE_WIDTHalready subtracts--chat-min-widthFixes #40494