Bug 188119 - [formatter] Formatting of comments longer than maximum line width
Summary: [formatter] Formatting of comments longer than maximum line width
Status: VERIFIED DUPLICATE of bug 293300
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P5 normal (vote)
Target Milestone: 3.6 M4   Edit
Assignee: Frederic Fusier CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-21 12:01 EDT by William Fulton CLA
Modified: 2010-03-04 11:56 EST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description William Fulton CLA 2007-05-21 12:01:23 EDT
Build ID: Build id: I20070222-0951

Steps To Reproduce:
In a new Java project, default settings that is shipped with Eclipse (in particular "maximum line width" for line wrapping set to 80 chars use tabs (4 characters wide), type in this code:

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");
	}
}

Hit CTRL-SHIFT-F once. The formatting changes 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");
	}
}

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");
	}
}

Comment: Hitting CTRL-SHIFT-F should not change anything second time around, especially here where it makes the formatting worse.


Also occurs in Version: 3.2.0 Build id: M20060629-1905
Comment 1 William Fulton CLA 2007-05-21 12:06:13 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.
Comment 2 Olivier Thomann CLA 2007-05-21 20:41:58 EDT
(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 ?
Comment 3 William Fulton CLA 2007-05-22 04:38:24 EDT
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.
Comment 4 Frederic Fusier CLA 2008-08-18 08:07:48 EDT
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
Comment 5 Frederic Fusier CLA 2010-01-13 06:52:29 EST
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 ***
Comment 6 Satyam Kandula CLA 2010-01-25 01:59:31 EST
Verified for 3.6M5 using build I20100122-0800
Comment 7 Olivier Thomann CLA 2010-03-04 11:56:35 EST
Verified.