Bug 300379

Summary:

[formatter] Fup of bug 287833

Product:

[Eclipse Project] JDT

Reporter:

Olivier Thomann <Olivier_Thomann>

Component:

Core

Assignee:

Frederic Fusier <frederic_fusier>

Status:

VERIFIED FIXED

QA Contact:

Severity:

major

Priority:

CC:

srikanth_sankaran

Version:

3.5.1

Target Milestone:

3.6 M6

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
Proposed patch	none

Description Olivier Thomann

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

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

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

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

2010-02-09 03:57:41 EST

Released for 3.6M6 in HEAD stream.

Comment 5 Srikanth Sankaran

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

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

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

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...