Community
Participate
Working Groups
Created attachment 78416 [details] source code for java formatting compare plugin Currently the JavaMergeViewer can ignore whitespace changes but this can be enhanced to ignore all java formatting changes. Sometimes in source code repositories you can find code that has been formatted with different formatter and comparing between revisions in this scenario is quite hard. I´ve developed a plugin that extends javamergeviewer to add this functionality. Unfortunately due to Bug #201116 this plugin it´s not functional in some configurations. So I think this plugin functionality can be added to the current JavaMergeViewer. Please find the attached source code for the plugin and some screenshots
Created attachment 78417 [details] screenshot: before ignore formatting changes
Created attachment 78418 [details] screenshot: after ignore formatting changes
Would it be possible to have a toolbar item to toggle this functionality?
After some thinking I think we should use the already existing 'Ignore whitespace' button on the toolbar to do this. Formatting is nothing else than adding whitespace (spaces, tabs, new lines). At the moment it seems that new lines are not counted as white spaces. Would you be interested to work on a patch that makes the 'Ignore whitespace' enabling/disabling your functionality? My feeling is that it shouldn't be to hard to fix the current implementation. So a minimal changes patch would be most welcome!
(In reply to comment #3) > Would it be possible to have a toolbar item to toggle this functionality? > The toolbar button it´s already implemented. If you look at the screenshot you´ll notice the little window/red cross at the top right corner.
(In reply to comment #4) > After some thinking I think we should use the already existing 'Ignore > whitespace' button on the toolbar to do this. Formatting is nothing else than > adding whitespace (spaces, tabs, new lines). At the moment it seems that new > lines are not counted as white spaces. > > Would you be interested to work on a patch that makes the 'Ignore whitespace' > enabling/disabling your functionality? My feeling is that it shouldn't be to > hard to fix the current implementation. So a minimal changes patch would be > most welcome! > Yeah, I´m interested. I´ll take a look into providing a patch. Stay tuned.
Created attachment 78937 [details] Patch to add ignore java formatting changes to the JavaMergeViewer. This patch applied to the current R3_3_maintenance adds a new functionality to ignore all java formatting changes not only whitespace changes on the same line. This functionality is enabled/disabled through "Ignore whitespace changes" in the Compare Preference Page.
Thanks Ruben for the patch! I think the feature makes sense, but I'm not sure if the patch takes the right approach. What I don't like is that the preview now shows a formated version. It also isn't editable anymore. It's not clear to me what happens when you modify the source in the compare editor (merge or manual edit) and then save. It would be more consistent with the 'Show Whitespace' feature when the source stays in it's original format, but whitespaces and line delimiters changes are ignored (if 'ignore whitespaces' is enabled). Note that you can toggle 'Ignore Whitespaces' while the compare editor is open ('Ignore Whitespaces' is on the toolbar). Looking the code, I think the reason why 'Ignore Whitespace' ends at line delimiters is the usage of the DocLineComparator in the DocumentMerger. The TextMergeViewer compares documents line by line. Therefore there's always a change when you have different line breaks. Adding Michael as the compare expert.
Michael, do you have an opinion here?
I think I agree with the assessment in comment 8. The current architecture of the TextMergeViewer restricts any model based involvement (e.g. Java) to involvement at the line level. I think that the proper solution to this problem would be to allow models to participate in the determination of differences at the document level. Last week (but not in 3.4 M2) I split out the document differencing code from TextMergeViewer. I think this is the first step. The final solution would require API that allowed models to override or extend the document differencing algorithm.
*** Bug 74751 has been marked as a duplicate of this bug. ***
