patrick91 / patrick91/shortcake
Unify the ls/ui tree renderer with the shared stack primitive
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 4
- Forks
- 0
- Avg merge
- 4h 22m
- Merged PRs (30d)
- 5
Description
sc submit and sc restack now render their stack through a shared primitive in
src/shortcake/_stack_view.py (build_layout + StackRenderer). _tree.py —
used by sc ls and the web UI — still has its own renderer, so there are two
tree layouts in the codebase.
Folding _tree.py into the primitive turned out not to be a mechanical
extraction, which is why it was left out of the original change.
Why it's blocked
The two renderers use genuinely different visual models:
_tree.py (ls, ui) |
_stack_view.py (submit, restack) |
|
|---|---|---|
| Direction | bottom-up (leaf first, trunk last) | top-down (base first) |
| Forks | parallel columns + merge connectors | indented arms |
| Content | commit subject, worktree paths, warnings, PR state | status column |
ls today:
│ │ ◯ add-world-module
│ │ │ Add world module
│ │ │
◯─┴─┘ add-hello-module
│ Add hello module
│
◯ main
Initial commit
submit today:
● add-github-repository-analysis-service #4672
│
├─● analyze-repositories-in-github-repository-list #4673
│ │
│ ● expose-github-repository-analysis-api #4674
│
└─● 2026-07-24-add-github-rate-limit-aware-client #4675
Sharing one layout means picking one of these and changing the other. That's a
UX decision about how ls should look, not a refactor — and ui.py builds on
the same StackTree, so the web UI changes with it.
Options
lsadopts indented arms. One layout everywhere. Changeslsoutput for
any forked stack, plus the web UI,tests/test_tree.pyand
e2e/docs/21-ls.md. Parallel columns arguably show sibling stacks better,
so this is a real loss for wide stacks.submitadopts parallel columns. Keepslsas-is, but the columns are
hard to reconcile with a status column and with viewport windowing, which
assumes one row per branch.- Share only the tree walk (parent → children, ordering, fork
detection) and keep two renderers on top. Smaller win, no visual change. - Leave both. The duplication is ~80 lines and neither renderer changes
often.
Option 3 is probably the best value if ls should keep its current look.
Notes
- Direction alone could be a parameter of
build_layout; the fork model is the
part that genuinely conflicts. - Whatever is chosen,
_tree.py's label content (commit subject, worktree
paths,⟳ needs restack, PR draft/merged/closed state) is orthogonal and can
stay where it is.
Contributor guide
No contributing guide indexed for this repository
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.
Research direction
Read src/shortcake/_tree.py and src/shortcake/_stack_view.py, then inspect the ls and ui entry points and the existing tests in tests/test_tree.py and e2e/docs/21-ls.md. Compare the four listed options with maintainers, especially the fork layout, status column, and web UI impact. Done means the chosen sharing or rendering strategy is implemented with the affected output and tests updated.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- cli, frontend
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100