Community
Participate
Working Groups
steps to reproduce: 1. In compare editor, open a file for 3-way compare 2. go to a diff that has some text on the left and empty text on the right 3. copy diff from right to left - the text on the left disappears - OK 4. undo - the text on the left reappears, but is no longer a part of the diff. To recalculate diffs, one would usually hit save, but this won't work in this case, as the compare editor is not dirty anymore.
extracted from bug 216407
Created attachment 229620 [details] patch v.1
The patch "works" but it has some issues: - it should only do this after undo, not in all cases where left and right are not dirty - it looks strange that you call doDiff() after setting fRedoDiff = false; - it makes no sense to call updateLines(doc) twice
Dani, can you tell me what is the impact of recalculating diffs in case the non-dirty state of the editor is reached in a way another than by Undo? As for calling doDiff() after setting fRedoDiff = false, I believe this makes sense, as it prevents us from running an unwanted, additional diff recalculation if a save was performed outside of the compare editor. This is BTW the only other scenario that I can think of, when the compare editor becomes not dirty other than by Undo-ing.
Created attachment 229767 [details] patch v.2 removed the redundant call to updateLines().
(In reply to comment #4) > Dani, > > can you tell me what is the impact of recalculating diffs in case the > non-dirty state of the editor is reached in a way another than by Undo? Performance. I thought about the case where the same document is open in another editor and the user reverts the changes. But in that case the #isRightDirty() will be 'false', and hence it's OK. > As for calling doDiff() after setting fRedoDiff = false, I believe this > makes sense, as it prevents us from running an unwanted, additional diff > recalculation if a save was performed outside of the compare editor. Agreed, though it does not matter at all, since the only place where that field is checked, is in #handleSetFocus, which should not be involved in the undo scenario at all. > This is > BTW the only other scenario that I can think of, when the compare editor > becomes not dirty other than by Undo-ing. Save does not trigger #documentChanged. Having said all that, I think we can go with your latest patch. Fixed with http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=2d3e21f97bf11d1bb5abb7fc1a426d2f2b377a54
(In reply to comment #6) > Fixed with > http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/ > ?id=2d3e21f97bf11d1bb5abb7fc1a426d2f2b377a54 This can cause an NPE, see bug 407436 for details.
