Prerequisites
- I have searched for duplicate or closed feature requests
- I have read the contributing guidelines
Proposal
An option on a diff item that lets the me name ranges of lines to render folded, the same way collapsedContextThreshold folds unchanged context: one separator row with a customizable label and an expand control, with the virtualizer's height estimates accounting for it.
foldedRanges?: Array<{
side: 'additions' | 'deletions';
start: number; // first line of the run, on that side
end: number; // last line, inclusive
label?: string; // separator text; falls back to "N lines"
}>;Expand is a lib-owned interaction like the context expander, with onFoldToggle or a controlled expandedFolds so I can keep the state. In split view a range folds both columns as one unit. An annotation whose line is inside a folded range either forces it open or is rejected, whichever is simpler.
Motivation and context
I currently force a feature to compute moved-code (lines of code that moved from file to another unchanged) and paint them through unsafeCSS plus a line annotation carrying the origin. Long runs still make the reviewer scroll past code that exists elsewhere in the same diff. Folding those rows is the natural next step (since it moved unchanged, I display it as a collapsed hunk), and only the lib can do it correctly: it owns row heights, the collapsed-context separators, annotation layout, split-view pairing and line selection. Hiding rows from outside with CSS would race all of those.
What exists today: collapsed folds the whole file; collapsedContextThreshold and expandUnchanged fold unchanged lines only. Nearest prior request is #331 (whole-file collapse, closed).
Version: @pierre/diffs 1.2.11.
Thanks.
Activity
2Hello! I'm working on auto-collapsing import lines at the beginning of a file/diff, i.e. creating a UX that is very similar to the existing N Unmodified lines bar but instead an N import changes bar.
Afaiu the feature/API that @Othmanosx is requesting/proposing for "externally flagging 'moved hunks' to be collapsible" would enable my use case as well. Thanks!
hey @amadeus, some context on who's asking since the contributing guide asks for it.
I built Pyor (https://pyor.review), a PR review client that renders every diff through
@pierre/diffs, web plus a desktop app. I review everything I ship in it, including Pyor's own PRs, so I stare at your diff surface a lot.I have probably done too many workaround to implement features that the diff list doesn't support, but this one cannot be done without a workaround, so I'm requesting it as a feature.
the thing I keep hitting: I compute moved code, a block that moved from one file to another unchanged, and right now I paint it with
unsafeCSSplus a line annotation carrying the origin. works fine, but on long runs the reviewer still scrolls past code that exists elsewhere in the same diff. the same shape shows up again for AI-written skim sections (a feature I'm working on), where a model names a range and I want it collapsed by default. both are parked on this issue.and I can't do it from outside the lib, the virtualizer owns row heights, the collapsed-context separators, annotation layout, split pairing and line selection, so hiding a row with CSS just leaves a gap and the file never shrinks.
anyway, I went ahead and implemented it on a branch off latest
mainto see if the idea held up. I'm not opening it as a PR, #810 suggests you'd rather talk about the shape first, and you'd probably design this differently than I did. happy to push it wherever's useful, or drop it entirely if you'd rather own the API.custom UI example:
a label on its own isn't enough for my case, I'd like to do more customization to match the function of this feature. the only existing way to own a separator's contents is the
hunkSeparatorsfunction and that's deprecated, so I followedrenderAnnotationinstead and addedrenderFoldSeparator(fold) => HTMLElement. if you've got a different successor in mind for that deprecated hook I'd rather build on yours. saw #884 is reshaping the decorations API next door, so this might want to land in the same shape.is a PR useful here, or would you rather take the design and do it yourselves? either's genuinely fine.