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) or file.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.
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:
VS Code Comparison
VS Code handles this with a dedicated diff editor:
file.java (Working Tree ↔ HEAD~1)orfile.java (index ↔ working tree). The full label appears in the editor breadcrumb and tooltip.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.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.:
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:
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.