Bug 300379 - [formatter] Fup of bug 287833
Summary: [formatter] Fup of bug 287833
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.5.1   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: 3.6 M6   Edit
Assignee: Frederic Fusier CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-21 10:12 EST by Olivier Thomann CLA
Modified: 2010-03-09 03:26 EST (History)
1 user (show)

See Also:


Attachments
Proposed patch (2.98 KB, patch)
2010-02-08 11:55 EST, Frederic Fusier CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Thomann CLA 2010-01-21 10:12:46 EST
Referring to:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=287833#c10

We missed one case. This is not related to the same problem, but should be fixed as well.
public class X {
    /**
     * <pre>   {@code
     * 
     *   public class X {
     *   }}</pre>
     */
    void foo() {}
}

which is both formatted with or without your patch as:
public class X02b {
    /**
     * <pre>
     * @code
     * 
     *   public class X {
     *   }}
     * </pre>
     */
    void foo() {
    }
}

The '{' before @code disappears.
Comment 1 Olivier Thomann CLA 2010-01-21 10:13:24 EST
Since there is loss of data, this is a must fix for 3.6M6.
Comment 2 Olivier Thomann CLA 2010-01-21 10:17:51 EST
The problem existed before the fix for bug 287833. This is not a new problem, so a fix for 3.6 only is fine.
Comment 3 Frederic Fusier CLA 2010-02-08 11:55:31 EST
Created attachment 158488 [details]
Proposed patch

While fixing bug 239719, I missed to handle the inline tags cases...
Comment 4 Frederic Fusier CLA 2010-02-09 03:57:41 EST
Released for 3.6M6 in HEAD stream.
Comment 5 Srikanth Sankaran CLA 2010-03-09 01:55:26 EST
Frederic,

I could verify that there is no data loss any more,
i.e the '{' is not swallowed by the formatter.

However, while formatting 
public class X {
    /**
     * <pre>   {@code
     * 
     *   public class X {
     *   }}</pre>
     */
    void foo() {}
}
I now get 
public class X {
	/**
	 * <pre>
	 * {
	 * 	&#064;code
	 * 	public class X {
	 * 	}
	 * }
	 * </pre>
	 */
	void foo() {
	}
}
Is this kosher ? For the HTML pre tag aren't we supposed to
preserve all line breaks and spaces ?
Comment 6 Frederic Fusier CLA 2010-03-09 02:29:59 EST
(In reply to comment #5)

I agree this look weird, but this is the behavior of the formatter since 3.3, hence this was not a regression when the formatting of comments was re-written in 3.4...

However, I tested this snippet with 3.2.2 and it worked properly, the formatter output is:
public class X {
	/**
	 * <pre>
	 * {
	 * 	@code
	 * 	public class X {
	 * 	}
	 * }
	 * </pre>
	 */
	public void foo() {
	}
}

It seems I missed to verify this when I implemented the fix. Could you open a new bug about this issue and close this one?

TIA
Comment 7 Srikanth Sankaran CLA 2010-03-09 03:20:43 EST
(In reply to comment #6)
> (In reply to comment #5)
> 
> I agree this look weird, but this is the behavior of the formatter since 3.3,
> hence this was not a regression when the formatting of comments was re-written
> in 3.4...

I wasn't quite referring to @ being transformed into the sequence
&#064; but to the line breaks and spaces being changed. Upon reading
the spec again, I don't think there is a bug here: Only the visual
rendering tools are not allowed to alter line breaks and such.

Verified for 3.6M6 using build I20100305-1011
Comment 8 Frederic Fusier CLA 2010-03-09 03:26:34 EST
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > 
> > I agree this look weird, but this is the behavior of the formatter since 3.3,
> > hence this was not a regression when the formatting of comments was re-written
> > in 3.4...
> 
> I wasn't quite referring to @ being transformed into the sequence
> &#064; but to the line breaks and spaces being changed. Upon reading
> the spec again, I don't think there is a bug here: Only the visual
> rendering tools are not allowed to alter line breaks and such.
> 
Oh, ok, hence the spaces and line breaks changes are expected because the formatter formats the code inside the <pre> tag according to the user profile...