#10 annoying editor problem

[the_mindstorm]

Hi!

Eclipse 3.0
Coffee-Bytes: 1.0.5a

Scenario: create a new class (see below exacty how it
looks), declare a new method and after the left
paranthesis a little pause is made. At this moment the
whole source is collapsed in the beginning comment.
The bug is annoying as there is no way to go back
(later I have discovered that presing Undo, Redo brings
you back on the typing position) to the point you are
typing being required to close and reopen the source in
the editor (the saved version is correct).

Template:
/*
* $Id$
*/
package net.noco.dtogen.util;

/**
* Class usage XXX
*
* @version $Revision$
*/
public class Test {
public static final boolean isTrue(
}

results in
/*[...]
public class Test {[...]
public static final void test([...]
}

In the above scenario: another settings: Advanced:
Minimum Number of Lines 2, checked method, control
structures, types.

After checking comments, in the same scenario the
source looks:
/*[...]
}

./pope

[R.J. Lorimer]

Logged In: YES
user_id=360457

Mindstorm - I haven't been able to reproduce this (that is
to say, I HAVE seen it once or twice, but I can't make it
happen again) - The above example confuses me some - there
are some items I can only assume are typos. Let me see if I
am right...

/*
* Blah
*/
package blah;

/**
* Blah
*/
public class Test {
public static final boolean isTrue(
}

turns into:

/*[..]
public class Test { [..]
public static final boolean isTrue( [..]
}

instead of what it SHOULD have been which is:

/*[..]
package blah;

/** [..]
public class Test { [..]

Am I correct? Any other information you can provide?

Thanks, R.J.

[the_mindstorm]

Logged In: YES
user_id=1064205

Yep you are right. Please ask me me about unclear descriptions.
The scenario is ALWAYS reproduceable :-(. I give it a try in
Eclipse 3.0.1 also and the same.

./the_mindstorm

[R.J. Lorimer]

Logged In: YES
user_id=360457

The code was attempting to find the 'most logical' brace to
match up in the case of mismatched tags. So, for instance:

1. public void myMethod() {
2. if(true)
3.
4.
5. }
6.
7. }

The code in the MethodStrategy was trying to fix the case
where a folding region would be produced for lines 1-5
leaving line 7 (the correct ending for 'myMethod') un folded
when the method was folded by the user. This is wrong; if
any line should be ignored, it should be line 5. The
defensive code was keeping track of the last 'left brace'
location, and using that on the outermost mismatched brace,
therefore overriding any inner blocks (e.g. lines 1-7 would
override lines 1-5).

Unfortunately, there are cases where this check fails.
Primarily, if there IS no previous brace. How is this
possible? Well, it is due to a quirk in the Eclipse Java DOM
parser. In short it occurs when the unfinished method
signature is the LAST method in the editor. Here is an
example compilation unit:

1. /*
2. blah
3. */
4.
5.
6. public class SomeClass {
7. public void myMethod()
8.
9. }

As you notice, this compilation unit has the infamous ()
unfinished method. Now, an IJavaElement (IMethod) is
produced with the source of lines 7-9. I was not aware that
Eclipse would actually produce an IMethod for anything until
it had a block body on it. Therefore, I didn't realize that
there would be a case where there could be a } without at
least one { available to match to. Keep in mind that line 6
is not part of the Imethod source code, so it doesn't apply.
Therefore, the last valid location pointer was never set
(set to 0), which is the first character of line 1. Now the
MethodStrategy has (erroneously) produced a folding region
for lines 1-9 because it couldn't find a valid prior block
to match to.

Here is where it gets interesting... The projection change
reconciler finds this new region in the result from the
calculator, and assumes it is the region on lines 1-3
because their offset is the same (the regions are
automatically repositioned as the user makes edits, so
offsets are safe to match on). Because of that, it simply
copies the location values from the new region over to the
region at 1-3 (assuming the calculator is smarter than the
editor reconciler). If the region at 1-3 was collapsed, the
effect of the entire editor collapsing occurs!

The fix was to simply handle the unusual case where the
method has no preceding left brace, and simply ignore the
corresponding right brace.