Fold unchanged regions in the unified diff - #2791
Conversation
|
This is a draft so that @tobiasmelcher can join in if he wants. Current state: Folding works but I have no way to unfold. 
|
9ab3ed5 to
b50fcaf
Compare
0c90f6e to
909ab3f
Compare
There was a problem hiding this comment.
Pull request overview
This pull request adds folding of unchanged regions to the experimental unified diff overlay in the Eclipse Compare UI, making large files with sparse changes more compact by collapsing unchanged gaps while preserving configurable context around each change.
Changes:
- Introduces a new
UnifiedDiff.Builder#foldUnchanged(int contextLines)option and wires it through toUnifiedDiffManager.open(...). - Implements unchanged-region fold computation and lifecycle management using the editor projection (folding) model, including teardown of added fold annotations.
- Adds “Expand n unchanged lines” code minings for collapsed fold regions and introduces a dedicated test suite for fold-region selection logic.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| team/tests/org.eclipse.team.tests.core/src/org/eclipse/team/tests/ui/UnifiedDiffFoldRegionsTest.java | New unit tests for computing which unchanged lines should be folded given diffs + context. |
| team/tests/org.eclipse.team.tests.core/src/org/eclipse/team/tests/core/AllTeamUITests.java | Registers the new fold-region test in the Team UI test suite. |
| team/bundles/org.eclipse.compare/compare/org/eclipse/compare/unifieddiff/UnifiedDiff.java | Adds the foldUnchanged(int) builder option and passes it to the manager. |
| team/bundles/org.eclipse.compare/compare/org/eclipse/compare/unifieddiff/internal/UnifiedDiffManager.java | Computes unchanged fold regions, adds/removes tagged projection annotations, and updates code minings when folds change. |
| team/bundles/org.eclipse.compare/compare/org/eclipse/compare/unifieddiff/internal/UnifiedDiffCodeMiningProvider.java | Adds fold-expander code minings based on collapsed fold annotations. |
| team/bundles/org.eclipse.compare/compare/org/eclipse/compare/internal/CompareUIPlugin.java | Enables unchanged-region folding with a default of 3 context lines when opening unified diff. |
| team/bundles/org.eclipse.compare/compare/org/eclipse/compare/internal/CompareMessages.properties | Adds NLS message keys for the fold-expander label(s). |
| team/bundles/org.eclipse.compare/compare/org/eclipse/compare/internal/CompareMessages.java | Adds corresponding NLS fields for the new expander messages. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
Hi Lars, thanks for adding code folding to the unified diff view! I tried it out and ran into a confusing interaction. When I click on line 6 and line 46, the fold indicator appears to be clickable, but no folding actually happens. The lines remain fully expanded after the click. I recorded a short screencast showing the behavior: code_folding_unified_diff.mp4I think the issue is related to the folding region starting at a line that is already collapsed by an "Expand ... In general, I like the feature. Clicking the "Expand ... unchanged lines" header annotation works perfectly fine. What are your plans for this? Should we merge the feature as-is, or would it make sense to first fix this interaction? With best regards, |
|
Hey Tobias thanks for testing and the feedback. I also think it will be quite useful especially in case of big files with only small changes. I left it in draft because I also found issues, for example if I increase the text size only parts of the unified display changes. I would like to leave it for now in draft, I testing at the moment the functionality and will return to this pr in a few days. During development I realized that compare was too slow and focused on this before working on new functionality. For example a 10 000 line file is or at least was too slow to be seen in unified diff. |
15e3eca to
f5ec0f6
Compare
|
Still some issues with this one.... |
bbbec75 to
14cd5eb
Compare
28b7998 to
469d5d4
Compare
469d5d4 to
f2e9cf8
Compare
@tobiasmelcher please re-test. |
f2e9cf8 to
78ef596
Compare
InlinedAnnotationSupport treated every annotation in fInlinedAnnotations as attached, so once a client removed a code mining annotation from the annotation model directly, the annotation was reused for every later render but never put back into the model and its minings stayed invisible. Annotations the model no longer knows are now added again. The fallback for annotation models without IAnnotationModelExtension now removes only the annotations that are actually gone, instead of dropping all of them and restoring only the newly added ones. Discovered while working on the unified diff of org.eclipse.compare, see eclipse-platform/eclipse.platform#2791 Assisted-by: multiple AI agents and layers of automated tooling 🤖
78ef596 to
a44e8c9
Compare
|
Depends on eclipse-platform/eclipse.platform.ui#4361 |
InlinedAnnotationSupport treated every annotation in fInlinedAnnotations as attached, so once a client removed a code mining annotation from the annotation model directly, the annotation was reused for every later render but never put back into the model and its minings stayed invisible. Annotations the model no longer knows are now added again. The fallback for annotation models without IAnnotationModelExtension now removes only the annotations that are actually gone, instead of dropping all of them and restoring only the newly added ones. Discovered while working on the unified diff of org.eclipse.compare, see eclipse-platform/eclipse.platform#2791 Assisted-by: multiple AI agents and layers of automated tooling 🤖
InlinedAnnotationSupport treated every annotation in fInlinedAnnotations as attached, so once a client removed a code mining annotation from the annotation model directly, the annotation was reused for every later render but never put back into the model and its minings stayed invisible. Annotations the model no longer knows are now added again. The fallback for annotation models without IAnnotationModelExtension now removes only the annotations that are actually gone, instead of dropping all of them and restoring only the newly added ones. Discovered while working on the unified diff of org.eclipse.compare, see eclipse-platform/eclipse.platform#2791 Assisted-by: multiple AI agents and layers of automated tooling 🤖
|
Thanks a lot Lars, looks really nice now. Unfortunately, I found a small issue after clicking the first "Show ... unchanged files" header annotation. The header mining jumps then back to the top of the document which doesn't feel right, it should have been disappeared from my point of view. Here a screencast: collapse_in_unified_diff.mp4I tested the changes of this pull request together with eclipse-platform/eclipse.platform.ui#4361 . Was that correct? |
InlinedAnnotationSupport treated every annotation in fInlinedAnnotations as attached, so once a client removed a code mining annotation from the annotation model directly, the annotation was reused for every later render but never put back into the model and its minings stayed invisible. Annotations the model no longer knows are now added again. The fallback for annotation models without IAnnotationModelExtension now removes only the annotations that are actually gone, instead of dropping all of them and restoring only the newly added ones. Discovered while working on the unified diff of org.eclipse.compare, see eclipse-platform/eclipse.platform#2791 Assisted-by: multiple AI agents and layers of automated tooling 🤖
a44e8c9 to
9b0f8ec
Compare
|
Hi Lars, I retested the latest changes locally together with eclipse.platform.ui#4361. The folding itself works well, but after expanding a folded region the "Hide 4 unchanged lines" code mining remains visible. I think the header should be an expander only and disappear once its region is expanded; the folding ruler can still be used to collapse it again. I tested the attached patch locally and it fixes this scenario. It creates unchanged-region code minings only for collapsed folds, removes the obsolete “Hide …” label, and adds a regression test which checks that the attached mining disappears after expansion. If this matches your intended interaction, could you please apply it with: fix-unified-diff-expander-mining.patch Thanks, |
|
Thanks @tobiasmelcher I think the "Hide 4 unchanged lines" is a useful feature. Sometimes I want to expand a part to see the x lines above the change and afterwards I want to hide them again. Here are some screenshots: 
|
Add a foldUnchanged(contextLines) option to UnifiedDiff that collapses the unchanged gaps between changes, keeping a few context lines around each change, similar to the unified view on GitHub. It reuses the editor's projection (folding) model, so it is a no-op when folding is disabled, and its folds are tagged so they can be removed without touching the editor's own folds. Each collapsed region shows a clickable "Show n unchanged lines" code mining that expands it in place, drawn as a band across the editor with an expander button, so it reads as a break between two hunks rather than as another line of the file. The band is a toggle: it shows a collapsed region and hides an expanded one again, so a region opened by mistake or read to the end can be put back without going to the folding ruler. Its label and the direction of its chevrons follow that state, and an expanded region's band sits above the block it would hide, because there is no gap to sit in. While it is collapsed the band belongs to the first line after its region. A collapsed fold keeps its own first line visible as the caption, so a band drawn above that line sat before a line that is still there while the lines it stands for were below it. The last line of the document is therefore never folded away, so that every region has a line after it to be drawn above. A "Fold unchanged regions" preference turns the folding on and off. It is on by default and shares a group with the existing unified diff preference on the Compare page. Attached code minings are reused only when they map one to one, by identity, onto the diffs shown; minings of diffs no longer shown are dropped. Collapsing a region can keep a mining from being created, and reusing what was left dropped that diff for good, because nothing recomputed it from the diffs afterwards. Reopening a diff in the same editor leaves the minings of the old diffs attached while the new ones are put, and a count cannot tell the two apart. Reopening also took the old code mining annotations out of the annotation model behind the back of the code mining framework, which never puts an annotation back that it believes to be attached. Next to a provider that answers asynchronously, as the Java editor's do, the request that would have dropped them is cancelled by the next one, and the rebuilt overlay minings landed on annotations that were no longer in the model. The manager now leaves those annotations to the framework. open() is split into an editor and a viewer level so that a reopen can be tested on a bare ProjectionViewer. Folds of the editor whose first line a collapsed region hides are taken out of the projection model while that region is collapsed and put back when it is expanded again. The folding ruler paints such a fold on the first line of it that is still visible but toggles it by its start line, so its indicator would sit on a foreign line and clicking it would do nothing. A region reaching the end of the document stops above the last line that carries content. A file ending in a line delimiter has an empty last line, and an annotation there is never redrawn, because the painter has neither a character nor a delimiter to repaint; the band of the last region stayed invisible. The band keeps its line when the region is toggled. Only two lines of a region are visible while it is collapsed, its caption and the line after it, so a band that sits at one end when collapsed and at the other when expanded moves by the whole height of the region under the pointer that just clicked it; for the region at the start of the file it landed on the first line of the document. Assisted-by: multiple AI agents and layers of automated tooling 🤖
9b0f8ec to
33a8139
Compare
Folds the unchanged regions of the experimental unified diff overlay, similar to the collapsed context in GitHub's diff view.
The gaps between the displayed changes are collapsed with three context lines kept around each change, which is what makes a large file with few changes reviewable at a glance:
AbstractTextEditor.javawith four changes fits on one screen instead of 8072 lines.Each collapsed region carries a clickable band that expands it in place and then reads "Hide n unchanged lines", so a region opened by mistake can be put back without going to the folding ruler.
The editor's projection model is reused and the folds are tagged, so tearing the overlay down leaves the editor's own folds alone; a fold the editor contributes inside a collapsed region is taken out while that region is collapsed, because its indicator would otherwise sit on a foreign line and do nothing when clicked.
A "Fold unchanged regions" preference on the Compare page turns the folding off; it is on by default.
Two known limitations.
Reusing projection support means this has no effect in an editor that does not install it, such as the default text editor.
And in a Java editor, revealing a line whose enclosing element is the whole type, a line in the class javadoc for instance, expands every region inside that type, because
JavaEditor.adjustHighlightRangeexposes the element's full source range.Needs eclipse-platform/eclipse.platform.ui#4361, which is merged.
Part of eclipse-platform/eclipse.platform.ui#3771
🤖 Generated with Claude Code
https://claude.ai/code/session_019P5XSUkajCGAiyxqAzgymD