Repository navigation
Unified Diff: Show compared revisions in editor title and reconsider presentation approach #2946
Description
Problem
When the unified diff is active in the Eclipse text editor, there is no indication of which two versions are being compared. The editor tab shows only the plain file name. Users have no way to tell at a glance whether they are looking at a comparison against the last saved version, a Git commit, a remote revision, etc.
This raises two related questions that should be addressed together:
- Editor title — how to communicate the compared revisions clearly.
- Presentation model — should the diff remain embedded in the file's own editor (current approach), or should it open in a dedicated comparison editor?
VS Code Comparison
VS Code handles this with a dedicated diff editor:
- Opening a diff (e.g. from the Source Control view) opens a separate editor tab, distinct from the file's normal editor. The file's own editor is unaffected.
- The tab title explicitly names both sides, e.g.
file.java (Working Tree ↔ HEAD~1)orfile.java (index ↔ working tree). The full label appears in the editor breadcrumb and tooltip. - VS Code also offers an inline diff toggle (toolbar button or
editor.diffEditor.renderSideBySide: false) that switches the dedicated diff editor between side-by-side and unified/inline presentation — but it always stays in the dedicated diff editor, never injected into the normal file editor. - Gutter indicators (colored bars) in the normal file editor show locally modified lines, but these are lightweight decorations, not a full diff presentation.
Expected Behavior for Eclipse Unified Diff
At minimum, the editor title (and tooltip) should reflect the compared revisions when unified diff is active, e.g.:
MyFile.java [Unified Diff: Working Tree ↔ HEAD]
Beyond that, it is worth considering whether the unified diff should be shown in a dedicated editor input (similar to VS Code's approach) rather than injected into the file's own editor. A dedicated editor would:
- make it unambiguous that the user is viewing a comparison, not the live file,
- allow the title to carry full revision metadata without cluttering the normal editor,
- avoid accidental edits to a "diff view" of a file the user did not intend to modify.
The current inline approach has the advantage of keeping context (folding, syntax highlighting, other decorations) but the revision identity problem is a real usability gap that must be solved regardless of which presentation model is chosen.
Activity
fedejeanne commentedon Sep 18, 2026
At the risk of stating the obvious, I'd like to add these usecases to the list and how they are shown by the 2-way compare for reference (look at the titles of the tabs):
danthe1st commentedon Sep 21, 2026
Because of the "issue" I explained in #2950, I think having a dedicated editor/always opening a new editor and not reusing it probably makes more sense.
The diff is logically different from viewing the current content and people may want to switch between the diff and the current editor (for some reason).
However, if a new editor is opened for the diff instead of reusing existing non-diff editors, I think you might want to consider closing the old diff editors when opening a new one (possibly conditional on a preference or similar which I think already exists in some form for the compare editor) to precent creating lots of diff editors when viewing many diffs.
DenisUngemach commentedon Sep 25, 2026
Hello, i would recommend to modify the existing compare editor and provide the unified diff view as a new perpective in the existing CompareEditor.
Opinions about this?
vogella commentedon Sep 25, 2026
perpective? If you mean new perspective I would think that would not be good. Also I don't think we need old and new in the same editor, I assume users will either use the old one or the new but not both.
iloveeclipse commentedon Sep 25, 2026
Views can't be added as perspectives and perspectives can't be added to editors. Can you please be more precise, what exactly do you propose here?
DenisUngemach commentedon Sep 25, 2026
No sorry i used the wrong word, not perspective but presentation.
I mean integrate the unified diff in the existing CompareEditor. Something like this:
But i have to say, i don't know whether this can be done this easily. The classical CompareEditor relies on two SourceViews and the UnifiedDiff relies on the AbstractTextEditor and integrates the new changes with code minings.
vogella commentedon Sep 25, 2026
I dislike the proposal but would not block it. So a weak -1 from me.
DenisUngemach commentedon Sep 25, 2026
Could you clarify why this is the case?
My expectation would be that a CompareEditor handles the visual diffing of two files with layout options (e.g., side-by-side vs. unified) rather than delegating to entirely different editor types.
This is analogous to how GitHub handles file comparisons:
with the layout split to:
vogella commentedon Sep 25, 2026
Maybe I misunderstood your proposal. We can already switch between unified diff and old compare.
DenisUngemach commentedon Sep 25, 2026
Yes, switching editors is possible, but my point is that I would prefer a single compare editor with two layout options rather than
two separate editors. This way, any UX improvements and features only need to be implemented once and apply to both layouts
consistently.
I doubt anyone would want to integrate a Java Structure Compare into the new UnifiedDiff the way it is done in the CompareEditor.
My goal is to switch from this two-sided layout:
to a unified layout within the same editor — without opening a new editor — resulting in something like this:
As mentioned before, I am not yet sure how this can be achieved with the currently existing UnifiedDiff implementation. But before
investigating the technical approach, I would first like to know whether this direction is desirable.
If it is, I believe this would address both open questions from this issue:
comparison editor?
Would this be an acceptable solution for this issue?
iloveeclipse commentedon Sep 25, 2026
Makes sense from UX point of view, absolutely.
vogella commentedon Sep 25, 2026
I'm not against this development (but also personally do not see value in it). Instead of text I would suggest to use icons similar to GH instead of text.
fedejeanne commentedon Sep 28, 2026
I don't have any strong opinions regarding how it should look like (text, icons, etc), as long as one can clearly see what is being compared (different versions of a file or 2 different files) and one can see if it's editable or not, I'm ok with any implementation ✔️
@DenisUngemach if your proposal about using a single compare editor with two layout options rather than two separate editors is viable and it makes maintenance easier, I'm all for it 👍
Thank you for looking into this, Denis 👏
DenisUngemach commentedon Oct 1, 2026
@fedejeanne
You're welcome, then it is only up to me, to evaluate whether this technically is a viable concept.
DenisUngemach commentedon Oct 6, 2026
It actually might be possible:
But it is not that simple. In order to keep the code coloring (which comes from the Java Compare Viewer, which lies in jdt and is not accessible in the compare plugin ), i have to take the left source viewer and let it fill the area and hide the right source viewer. Then add the code minings and it looks like that.
This might be a bit hacky to implement.
danthe1st commentedon Oct 6, 2026
Wasn't the idea of the unified diff that it basically works with any text editor while preserving the specifics of what that editor is doing? Would it still be possible to use e.g. syntax highlighting, hover or other functionality when the unified diff is added to the conpare editor instead?
DenisUngemach commentedon Oct 6, 2026
As I understand the introduction of this issue, this must be discussed.
From my side i wanted to check, whether it is even possible to use the CompareEditor with a unified diff layout.
It should be possible to use all the features already integrated in the CompareEditor framework, which actually means it depends on the available compare features of the extensions.
I think the crucial point is:
You either get the full Compare Editor feature set or the full Text Editor capabilities, but never both.