Community
Participate
Working Groups
Sometimes its useful to prevent the code formatter from formatting some blocks of code (e.g. when defining an array where it helps to have the contents laid out in some way). I suggest that the lines of code to be untouched by the formatter could be marked by a comment: // UNFORMATTED ... // UNFORMATTED
Perhaps an annotation would be better. This would allow some finer grained control through parameters. E. g. one could allow format-changes like whitespace before and after "=" sign etc., while still preventing indentation and line endings to be changed. @Unformatted public void someMethod() { String[] myArray = new String[] { "A", "B", "C", "1", "2", "3", "D", "E", "F", "5", "6", "7" }; }
An annotation would have to be defined somewhere. But I don't think people would want to have annotations from within eclipse namespaces just for controlling the code formatter. So I'd rather go with the comments. If necessary, they could be made to control individual formatting aspects as well. I'm going to give the version with the comments a shot.
Created attachment 73721 [details] Proposed patch I added a patch which implements this (including a test case). It triggers on line comments which contain DO NOT REFORMAT BELOW THIS LINE to disable the formatter, and DO NOT REFORMAT ABOVE THIS LINE to re-enable it. They can be nested. As far as I could tell, there are no functional formatter regressions. There might be a slight performance regression, but I don't think this is crucial in the formatter. While I don't think it's necessary, I could make this configurable. If so, then I would also make the comment strings configurable.
I've just realized that it still reformats long line comments. Maybe also block comments. I shall check and upload a revised patch.
I've spent some time trying to figure out how to prevent line wrapping in comments within unformatted blocks. But it looks harder than I thought. The problem is that comment line wrapping is done in DefaultCodeFormatter.format when given the type K_xx_COMMENT and *only the current comment* as context. So it has no good way to see if it should format this comment or not. The caller, CommentFormattingStrategy is in a UI package, so harder to test. This class would have the necessary context to check for the DO NOT FORMAT markers, but it would probably not be cheap.
I believe this is a dup of a bug I cannot find. Olivier any idea ?
*** Bug 195894 has been marked as a duplicate of this bug. ***
Ownership has changed for the formatter, but I surely will not have enough time to fix your bug during the 3.5 development process, hence set its priority to P5. Please finalize the posted patch if you definitely need the bug to be fixed in this version and I'll have a look at it... TIA
This bug is a duplicate of bug 27079, which is already fixed (target milestone: eclipse 3.6 M6). The fix introduces special tags to disable/enable the code formatter. The tags can be changed in the formatter options. (Unfortunately, I do not have the permissions to change state or resolution of this bug...)
(In reply to comment #9) > This bug is a duplicate of bug 27079, which is already fixed (target milestone: > eclipse 3.6 M6). > > The fix introduces special tags to disable/enable the code formatter. The tags > can be changed in the formatter options. > > (Unfortunately, I do not have the permissions to change state or resolution of > this bug...) Correct, thanks for having pointed this :-) *** This bug has been marked as a duplicate of bug 27079 ***
Verified for 3.6M7 using build I20100424-2000
Verified.
