Bug 6721 - Error with code formatter style
Summary: Error with code formatter style
Status: CLOSED INVALID
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 2.0 M2   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-12-10 09:06 EST by Ray Elenteny CLA
Modified: 2003-03-17 11:47 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.