Problem
The current unified diff presentation has two related UX gaps:
-
No version context in the editor title. When the unified diff is shown in the open file editor, the tab title displays only the file name. There is no indication of which two versions/revisions are being compared (e.g. "working tree vs. HEAD" or "local vs. remote"). Users cannot tell at a glance what the diff represents.
-
Diff shown in the regular file editor. The diff is overlaid onto the normal editor for the file. It is an open question whether this is the right model, or whether a dedicated comparison editor should be opened instead — similar to how Eclipse's existing 2-way TextMergeViewer works.
VS Code Comparison
VS Code's approach to diff presentation serves as a useful reference:
- Separate diff editor: When opening a diff from Source Control (e.g. clicking a changed file), VS Code opens a dedicated Diff Editor — a separate editor tab, not the regular file editor. The two versions are shown side by side (or inline).
- Tab title shows both versions: The diff editor tab title clearly identifies what is being compared, e.g.
file.java (Working Tree ↔ HEAD) or file.java (index ↔ working tree). The exact label depends on the Git comparison context.
- Inline diff mode: VS Code supports an inline diff view as an alternative to side-by-side. It is toggled via the "Inline View" button in the diff editor toolbar or via the setting
"diffEditor.renderSideBySide": false. In inline mode the deleted and inserted lines are interleaved in a single column — still within the dedicated diff editor, not the regular file editor.
- Gutter decorations and breadcrumb: In addition to the tab title, the diff editor shows a breadcrumb / header indicating the two refs being compared, and the overview ruler marks the distribution of changes.
Expected Behavior / Questions to Resolve
- The editor title (or a subtitle / breadcrumb) should clearly show which two versions are being compared whenever a unified diff is active.
- It should be evaluated whether the unified diff should continue to be shown in the regular file editor, or whether a dedicated comparison editor (analogous to VS Code's diff editor) would be a better fit for discoverability and clarity.
Problem
The current unified diff presentation has two related UX gaps:
No version context in the editor title. When the unified diff is shown in the open file editor, the tab title displays only the file name. There is no indication of which two versions/revisions are being compared (e.g. "working tree vs. HEAD" or "local vs. remote"). Users cannot tell at a glance what the diff represents.
Diff shown in the regular file editor. The diff is overlaid onto the normal editor for the file. It is an open question whether this is the right model, or whether a dedicated comparison editor should be opened instead — similar to how Eclipse's existing 2-way
TextMergeViewerworks.VS Code Comparison
VS Code's approach to diff presentation serves as a useful reference:
file.java (Working Tree ↔ HEAD)orfile.java (index ↔ working tree). The exact label depends on the Git comparison context."diffEditor.renderSideBySide": false. In inline mode the deleted and inserted lines are interleaved in a single column — still within the dedicated diff editor, not the regular file editor.Expected Behavior / Questions to Resolve