Community
Participate
Working Groups
During our development we often compare local files but also a local file with another version of it (contained in the scm system). There we often face the problem that the "other" file is e.g. not formatted the as our code. It would be nice if the "other" file is preformatted before showing it in the compare editor. Preferrably the "Save action" shall be applied to the file content before showing it in the compare editor.
Comparison can be toggled to ignore whitespace differences, which is all formatters are allowed to modify (in theory). Is there more you need ?
Formatting is the first step but what would be ideal is to have the same format for e.g.: - parentheses in conditions - block syntax of loops/ifs conditions - "this" qualifier for members - Class qualifiers for static members If complete save action would be applied so that the complete file is "transformed" I would get much less diffs than by just ignoring the whitespaces. Greetings Marko
Philippe, I wonder if you know is the "complete save" called for Java Editor somehow different then the one currently available when editing a resource in Compare Editor? In other words, are on-save-actions which could do the formatting available only for Java Editors? If so, this looks like another blocker for bug 169386.
*** Bug 381626 has been marked as a duplicate of this bug. ***
*** Bug 385996 has been marked as a duplicate of this bug. ***
Files on disk / in scm-repository 1 Read Display in Compare-Editor 2 Save Files on disk As the duplicate bug has been reopened solely for step 2, lets focus this bug on step 1. The "Save-Actions" can be seen as a universal code reformat and cleanup filter. Indeed, it would be nice, to apply them on the fly before performing the comparison. To be more specific, there could be situations, where you selectively apply the filter only to the first or the second file. Especially something like sorting members will perform poorly when it comes to renaming/refactoring methods. If such a "structural" filter is equally applied to both sides, you cannot see if there were additional changes within the method (e.g. recursive calls) or if it was a pure rename. Moreover I don't see any reason, why to tether this genuine new feature with the existing save-actions for step 2. A default would surely propose to link to them. But this should be overwrite-able the same way, a projects preferences inherit from the workspace settings. If the mechanism is already in place, it would be nice to derive a second layer for specific filter actions per source. BTW: As we often have a three-way-compare: would it be necessary to also filter the common ancestor?
See also bug 45423.
