Bug 6721

Summary: Error with code formatter style
Product: [Eclipse Project] JDT Reporter: Ray Elenteny <raye>
Component: CoreAssignee: Olivier Thomann <Olivier_Thomann>
Status: CLOSED INVALID QA Contact:
Severity: normal    
Priority: P3    
Version: 2.0   
Target Milestone: 2.0 M2   
Hardware: PC   
OS: Windows 2000   
Whiteboard:

Description Ray Elenteny CLA 2001-12-10 09:06:05 EST
I am using build 20011206 and when configuring the code formatter I have found 
a couple of problems in the style tab.  First, if I go to change the "Number of 
spaces representing a tab" by deleting the current entry, I get an internal 
error.  If I dismiss the dialog, I can enter the value fine.  Second, if I 
uncheck "Indentation is represented by a tab" and I have "Insert a new line 
before opening a brace" checked, the curly brace under the try is indented one 
extra space.  If I accept the settings and fomat some code, the extra space is 
added in the code as well.
Comment 1 Olivier Thomann CLA 2001-12-13 10:46:40 EST
Could you please provide us a test case that would point to the problem? It is 
much faster for us to track down a bug with a test case than without.
Thanks for the report.
Comment 2 Ray Elenteny CLA 2001-12-14 08:03:11 EST
You can see the problem right in the Code Formatter Preferences Dialog.  For 
the "New Lines" tab, I have "Insert a new line before an opening brace" 
and "Insert new lines in control statements" checked.  The "Line Splitting" tab 
option "Maximum line length is set to "100."  In "Style" tab, by default 
the "Indentation is represented by a tab" checkbox is selected.  If you uncheck 
it, you will see that the curly brace under the "try" will move out of line 
with the other curly braces.  Checking the box again, will starighten out the 
brace.

I hope this is enough for you.  If not let me know.  Thanks!
Comment 3 Olivier Thomann CLA 2001-12-14 13:12:06 EST
This is fixed with the latest changes in the formatter. This is released in 
HEAD. See the release notes of JDTCORE to know when this is integrated in the 
integration builds.
Comment 4 Olivier Thomann CLA 2001-12-17 12:40:47 EST
Need to double-check the fix with the UI containing the new API for the 
formatter.
Comment 5 Olivier Thomann CLA 2001-12-18 15:17:46 EST
This is not fixed in build 1218. I don't understand why I cannot reproduce it 
using the formatter in standalone with the same string that is used in the 
formatter preferences panel.
I need to figure out why the extra space is still there.
Comment 6 Olivier Thomann CLA 2001-12-18 15:30:41 EST
If I use the formatter in standalone mode, from:
{

if (size < currentSize) {
try {
size = inStream.available();
} catch (IOException e) {
}
}
else if (size == currentSize) {
++size;
}
else {
--size;
}

}

I got:
{

    if (size < currentSize)
    {
        try
        {
            size = inStream.available();
        }
        catch (IOException e)
        {
        }
    }
    else if (size == currentSize)
    {
        ++size;
    }
    else
    {
        --size;
    }

}

This is what is happening when the options is changed. There is no extra space 
with the opening curly brace of the try statement.
Comment 7 Olivier Thomann CLA 2001-12-20 11:43:06 EST
I think I understand why I couldn't reproduce it using the formatter in 
standalone. You visually see an extra space, but if you actually count the 
number of space, it is ok. I might come from the font used to see the formatter 
settings. This happens only when it is following a keyword which are in bold. If 
you don't display the keyword in bold, then you don't see anymore a shift of the 
curling brace.
You can change the keyword rendering:
Workbench>Preferences>Java>Editor>Color.
Select keyword and uncheck bold on the right.
Thanks for the report. It is always useful to report apparent bug.
Comment 8 Ray Elenteny CLA 2001-12-20 12:00:37 EST
Thanks for the work on this issue.  Sorry to create all the work for nothing!
Comment 9 Olivier Thomann CLA 2001-12-20 12:22:32 EST
No problem. This could have been a bug and we should always log a PR when we 
think we found a bug. Even if sometimes there is no bug, it's worth checking it.