Unified Diff: Disable when opening the file again / Reusing editor should disable unified diff

Open
#2,950 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
java
Domain
desktop, tooling

Research direction

Start by tracing how the Compare/Patch unified diff preference opens and reuses editors, then check the reopening paths from the project/package explorer and Ctrl+Shift+T. Done means reopening a file no longer preserves the unified diff, while opening a comparison still shows it as intended.

Written by the indexing model from the issue text.

Description

enhancement

Suggestion

When I view a diff using the new unified diff option, don't close the file and then open the file in some way, the unfied diff is still shown.

From a fresh installation and clean workspace:

  • Enable Window > Preferences > Compare/Patch > Use Unified diff ...
  • Create a project with two files, e.g. Test.txt and Test2.txt with some difference
  • Select both and right click > Compare With > Each other

It then shows the diff between the files as intended:

Image

If I then double-click the file in the project/package explorer, I still see the editor with the diff.

When trying to open the file again, Eclipse shouldn't show me the diff any more but only the file.

Considered approaches

I could see the following possibilities of implementing this

  • When a file is opened and reused, the unified diff is cleared if possible
  • When an editor is opened using the unified diff, it is not reusing an existing editor but opening a new one and making sure that one isn't reused. When opening another editor in the unified diff, it may be a good idea to close/replace the old unified diff editor (I think there's also a preference for reusing the 2-way compare editor?)

This should be ensured when opening the file via the project/package explorer or via other ways (e.g. Ctrl+Shift+T for Java types).

Community

  • I understand suggesting an enhancement doesn't mandate anyone to implement it. Other contributors may consider this suggestion, or not, at their own convenience. The most efficient way to get it fixed is that I implement it myself and contribute it back as a good quality patch to the project.
Dominant language
Java
Stars
165
Forks
174
Avg merge
1d 19h
Merged PRs (30d)
22

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from eclipse-platform/eclipse.platform

All issues in eclipse-platform/eclipse.platform

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.