Regression: Plan tab reading-column cap is back (fixed in v1.1.12 via #2888, broken again in v1.1.22)
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 55/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- markdown
- Domain
- desktop
Research direction
Start at the workspace Plan tab's rendered markdown view and compare its behavior with the #2888 fix from v1.1.12. Reproduce with the provided column ruler while widening or maximizing the panel. Done means rendered text uses the available width and a regression test covers the reflow behavior.
Written by the indexing model from the issue text.
Description
Summary
This is a regression of #2888 (fixed in v1.1.12). The Plan tab's rendered markdown view again caps prose to a fixed reading column (~95-100 characters) instead of using the available panel width. Reproduced on v1.1.22.
The original bug (#2888) was closed as fixed in v1.1.12; the reflow behavior has since regressed. This is distinct from the chat/conversation-view width issues (#3195, #3795) - it is specifically the workspace Plan tab.
What happens
Widening the panel or the whole window - including Maximize Panel - does not reflow the rendered text; it stays in the same narrow column with dead space on the right. The <> code view of the same plan has no such cap and runs edge-to-edge.
Steps to reproduce
- Open a session so the Plan tab is visible (close and re-open the tab to force a fresh render).
- Use a plan whose body contains this column ruler (each label sits at its true character column):
--------10--------20--------30--------40--------50--------60--------70--------80--------90-------100-------110-------120-------130-------140-------150-------160
- View the rendered Plan tab, then widen the panel / click Maximize Panel.
Expected
The rendered text reflows to use the available panel width, as it did after the #2888 fix in v1.1.12.
Actual
Text wraps at ~column 96 regardless of panel or window width - the ruler breaks right after the 90 label even in a maximized panel. The <> code view is unaffected (full width).
Environment
- App version: 1.1.22 (regressed; last known good: v1.1.12)
- OS: Windows
- Surface: workspace Plan tab (rendered markdown view)
Related
- #2888 - original report, fixed in v1.1.12, now regressed (this issue)
- #2608 - same class of reflow bug in the MD Editor, fixed in v1.1.6
- #3195, #3795 - chat/conversation-view horizontal-space issues (different surface)
Suggested fix
Restore the #2888 reflow fix for the Plan tab's rendered view, and consider a regression test so this surface's reflow doesn't break again. A width preference (e.g. 120 / 140 / full-width) for rendered markdown surfaces would also help.
- Dominant language
- No language data
- Stars
- 2.1k
- Forks
- 157
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from github/app
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
Similar issues
-
comp/desktop P3 type/bug
Difficulty 1/5 Under an hour Newbie friendliness 92/100
NousResearch/hermes-agent#118866 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
Help-Wanted Package-Request
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
microsoft/winget-pkgs#438682 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Automattic/studio#4908 ·
-
bug popups
Difficulty 2/5 1-3 hours Newbie friendliness 76/100