Community
Participate
Working Groups
Build ID: I20080502-0100 Steps To Reproduce: 1. Create a block comment with whitespace formatting that starts with /*- 2. Run the Eclipse [built-in] formatter 3. Whitespace will be stripped out, rendering comments that contain lists or tree diagrams unreadable More information: Sun's code conventions (http://java.sun.com/docs/codeconv/html/CodeConventions.doc4.html#385) say the following: Block comments can start with /*-, which is recognized by indent(1) as the beginning of a block comment that should not be reformatted. Example: /*- * Here is a block comment with some very special * formatting that I want indent(1) to ignore. * * one * two * three */ The above example is being turned into: /* * - Here is a block comment with some very special formatting that I want * indent(1) to ignore. * * one two three */ Eclipse 3.3's formatter respected /*-.
Created attachment 99349 [details] Proposed patch
No regression noticed with this patch on Eclipse 3.0 and Ganymede workspaces tests. Olivier, could you please review?
Patch looks good. +1 for 3.4RC1.
Released for 3.4RC1 in HEAD stream.
Verified for 3.4RC1 using build I20080510-2000.
I have found a problem with the fix in I20080516-1333. In the following code, the first block is prefixed "/*-", and the second is prefixed with "/*- " (with a space after the dash): /*- * Foo bar */ /*- * Foo bar */ When run through the formatter, it strips out the line with "/*-": * Foo bar */ /*- * Foo bar */ Any character (except for a return) after the - will prevent the line from being stripped.
Reproduced. The problem comes from the fact that in this case, the scanner need to be reset from the comment start (e.g. before the /*) to indent properly the entire comment. Unfortunately, it works when there's a space and this made me missed this point...
Created attachment 101574 [details] Additional patch to fix the remaining issue
Olivier, Jerome, could you please review?
+1. Current implementation is losing code. So this is critical (data loss).
looks good - obvious fix
I also feel this needs to be addressed for RC2, since this is a regression introduced by the 1st change.
Released for 3.4RC2 in HEAD stream.
Verified for 3.4RC2 using build I20080523-0100
