Summary: | [formatter] Formatting of comments longer than maximum line width | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | William Fulton <wsf> |
Component: | Core | Assignee: | Frederic Fusier <frederic_fusier> |
Status: | VERIFIED DUPLICATE | QA Contact: | |
Severity: | normal | ||
Priority: | P5 | CC: | frederic_fusier, Olivier_Thomann, satyam.kandula, srikanth_sankaran |
Version: | 3.3 | ||
Target Milestone: | 3.6 M4 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
William Fulton
2007-05-21 12:01:23 EDT
So the bugtracker has chopped everything at 80 chars or so, so what you see is not what the Editor displays. Never mind, following the actions will show that in the 2nd snippet of code, the comment start (//) are nearly lined up (out by 1 character) whereas in the 3rd snippet of code, they are way out. (In reply to comment #0) > Which doesn't quite line up (it is out by one character), but more importantly > hitting CTRL-SHIFT-F changes the formatting to: > public class Start { > public static void addHistTest() { // a comment that is longer than the > // maximum number of characters allowed > // on a line > System.out.println("hi"); > } > } The formatter doesn't know that the three comments are "linked". What you mean is that continuous line comments should always be aligned ? yes, comments that span multiple lines should be aligned. The formatter aligns the comments correctly when there is no code preceding the comment on that line, eg // comment1 // comment2 System.out.println("..."); but it gets it wrong when the comment spans multiple lines, where the first line of the comment also contains code, eg the result of formatting System.out.println("..."); // comment1 // comment2 becomes: System.out.println("..."); // comment1 // comment2 That kind of makes sense why it does this, but when the formatter breaks a comment into more than one line, it should consistently generate the same formatting, so that a second CTRL-SHIFT-F doesn't change the format again. 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 provide a patch if you definitely need the bug to be fixed in this version and I'll have a look at it... TIA The formatter behaves correctly since 3.6M4 on the test case provided in comment 0. This is mainly due to the fix for bug 293300... *** This bug has been marked as a duplicate of bug 293300 *** Verified for 3.6M5 using build I20100122-0800 Verified. |