You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are few default compare in Eclipse which I always change in every workspace since years. #3775 reminded me about them.
I believe the defaults can be improved.
Show structural changes in the Outline (feature introduced via https://bugs.eclipse.org/bugs/show_bug.cgi?id=45247).
By default is is off, which wastes almost 1/3 of the compare editor. That is exact the reason why it makes sense to enable the feature, so the space is not wasted.
Default:
Proposed:
Connect ranges with single line. This is very old, it seem that the option was introduced at 2.1 Eclipse via https://bugs.eclipse.org/bugs/show_bug.cgi?id=31357 and just no one cared to enable it by default. Single line is harder to see, so the "line ranges" (no idea how that is officially named) is visually more appealing and helps better identify flow of the changes.
Default:
Proposed:
Change default diff panes order to follow "usual" diff order - left is base/original, right is local/modified.
Default in Eclipse is the opposite, I believe from the CVS times where there were no new/old but local/server, and someone arbitrary decided that local should be left. That was probably OK at that time, but now where everyone uses git it is awkward to see diff panes shown in "wrong" order by default in Eclipse, where rest of the world does the opposite. See for example https://www.jetbrains.com/help/idea/comparing-file-versions.html.
The possibility to change the order was introduced via https://bugs.eclipse.org/bugs/show_bug.cgi?id=213780). The request to change the default is https://bugs.eclipse.org/bugs/show_bug.cgi?id=501752, but there were some test fixes needed, no time and no one continued the work. I believe now we should finally do that change.
Of course changing defaults can be controversial and surprising, but I too did not know about all these settings. (And I always have Oomph so I can change any default I don't like once and for all everywhere.)
I think that only the mirroring is catching people off guard. The new style is quite nice and with the improvements we did for supporting the inline-merge buttons in the new style, I don't think that's so controversial. The outline just seems like a good thing. Seeing the opposite of what one expects to see is really disconcerting (for me).
I think that only the mirroring is catching people off guard.
Back in 2016 there seemed to be some agreement that swapping is good IFF the user is clearly notified about this change, see bug 501752 comment 10, comment 12, comment 15. Has this been considered in the recent effort?
Have different uses within the SDK be checked for effects? I'm chiefly thinking of Team Compare, Refactoring Preview and JUnit Test Result (Expected | Actual). In particular if the latter is flipped to (Actual | Expected) that would seem bad to me.
I also have problems identifying what is what. But I think that might be more due to the poor labels / display of the label. A clearly identifiable label might help.
Have different uses within the SDK be checked for effects? I'm chiefly thinking of Team Compare, Refactoring Preview and JUnit Test Result (Expected | Actual). In particular if the latter is flipped to (Actual | Expected) that would seem bad to me.
In my understanding, it was the primary concern that inverting the default may be fine for some use cases but not for others and an investigation of different uses cases did not happen so far. Doing an analysis of different use cases before applying such a change is what I also proposed in #3776 (comment).
Activity
Show structure compare in Outline view by default
Use line ranges in compare editor by default
Use "natural" diff order by default in compare editor
Incorrect Colors in LTK Refactoring Preview Wizard
BeckerWdf commentedon Mar 13, 2026
All of your proposals make a lot of sense for me. Let's go for it.
HeikoKlare commentedon Mar 13, 2026
I also like all of the proposals and would be in favor of changing those defaults. I wasn't even aware of some of the options or their effects.
iloveeclipse commentedon Mar 13, 2026
:-) That is also my impression while pair coding with other developers.
merks commentedon Mar 13, 2026
Of course changing defaults can be controversial and surprising, but I too did not know about all these settings. (And I always have Oomph so I can change any default I don't like once and for all everywhere.)
vogella commentedon Mar 13, 2026
+1 for the change
Updated tests to consider "natural" diff order by default
Fix MirroredMergeViewerContentProvider not mirroring errors
Show structure compare in Outline view by default
Use line ranges in compare editor by default
26 remaining items
merks commentedon May 5, 2026
I think that only the mirroring is catching people off guard. The new style is quite nice and with the improvements we did for supporting the inline-merge buttons in the new style, I don't think that's so controversial. The outline just seems like a good thing. Seeing the opposite of what one expects to see is really disconcerting (for me).
iloveeclipse commentedon May 5, 2026
Here is the poll: #3967
stephan-herrmann commentedon May 5, 2026
Back in 2016 there seemed to be some agreement that swapping is good IFF the user is clearly notified about this change, see bug 501752 comment 10, comment 12, comment 15. Has this been considered in the recent effort?
Have different uses within the SDK be checked for effects? I'm chiefly thinking of Team Compare, Refactoring Preview and JUnit Test Result (Expected | Actual). In particular if the latter is flipped to (Actual | Expected) that would seem bad to me.
stephan-herrmann commentedon May 5, 2026
Would eclipse-egit/egit#178 help?
HeikoKlare commentedon May 6, 2026
In my understanding, it was the primary concern that inverting the default may be fine for some use cases but not for others and an investigation of different uses cases did not happen so far. Doing an analysis of different use cases before applying such a change is what I also proposed in #3776 (comment).
iloveeclipse commentedon May 6, 2026
I hope people who use milestones and nightly builds do that and report the inconsistencies if they encounter some.
This is the main one, so it should work
This was actually the trigger for the whole story here, and yes, it is fixed, see #3777
Now you mentioned that one, I've pushed the fix, very similar to #3777 it was always inconsistent for exact same reason :-)
Make JUnit diff order consistent with the default compare diff order
Make JUnit diff order consistent with the default compare diff order
Make JUnit diff order consistent with the default compare diff order
iloveeclipse commentedon May 18, 2026
The results (as of today) from #3967 are:
I've pushed PR for N&N changes : eclipse-platform/www.eclipse.org-eclipse#549
With that, I consider that we can keep proposed changes in 4.40 and close this ticket.
Add note about changed Compare editor defaults
Add note about changed Compare editor defaults
Add note about changed Compare editor defaults
Add note about changed Compare editor defaults