Summary: | [formatter] Code Formatter: Markup sections to omit from formatting | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Channing Walton <channingwalton> | ||||
Component: | Core | Assignee: | Frederic Fusier <frederic_fusier> | ||||
Status: | VERIFIED DUPLICATE | QA Contact: | |||||
Severity: | enhancement | ||||||
Priority: | P5 | CC: | clovis.seragiotto, dan.j.allen, eclipsebugs, jarthana, jerome_lanneluc, Konstantin.Scheglov, mario.winterer, satyam.kandula | ||||
Version: | 3.2 | ||||||
Target Milestone: | 3.6 M6 | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Channing Walton
2006-02-20 08:36:55 EST
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. |