This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
NetBeans IDE Dev (Build 20061120-0828) 1.6.0-rc; Java HotSpot(TM) Client VM 1.6.0-rc-b104 Windows XP version 5.1 running on x86 en_US (nb); Cp1252 Code folding is broken when new method is added to the file where is extra '}' at the end. Steps to reproduce: 1) have class: public class Test { public void method1() public void method2() { } } } 2) type '{' behind the head of method method1 and press enter -> closing '}' is not added -> fold is created w/o marked end 3) collapse the 1st fold -> it cannot be unfolded, while clicking on 'plus' symbol will collapse/expand the 2nd fold, 1st is still folded
Created attachment 36248 [details] screenshot
Yeah, this is broken. I am not familiar with the code folding implementation, but could not we simply assume that if FoldManager provides two overlapping folds at *the same* level the first one ends where the second one begins. There is no point in having overlapping folds anyway. FoldManagers should not be allowed to return overlapping folds and if they do it means that something is broken with that FoldManager. The infrastructure should detect this situation and handle it gracefully.
Any fold can be unfolded by double-clicking on it including this case. The fold hierarchy checks for overlapping folds and does not permit them. But in this case the folds are not overlapping - the java infrastructure ends the first fold before the declaration of the method that follows. You can verify it if you go to navigator and select "Trees" view. So the only thing that could IMHO be improved on the editor side is that the click on "+" for collapsed folds would uncollapse *all* the collapsed folds present on the given visual line. Is that desirable?
I see, multiple folds on the same line are quite tricky to handle. You don't need broken java code, the same problem happens for example in this situation: public void a() { } public void b() { } or <tag> </tag><tag> </tag> I think that [-]/[+] should collapse/expand *all* folds that are defined on the line, which the fold handle was created for. It would be more predictable behavior. I for example didn't know that clicking a folded fold expands it. How do eclipse or idea deal with this situation?
Idea behaves exactly like we do incl. inability to expand the first fold and the double-click to expand :) Ecl. hides the whole line where a fold ends so it's strange as when folding the first method the next method's header disappears completely.
So, we are not doing that bad afterall. :)
*** Issue 75273 has been marked as a duplicate of this issue. ***
Fold can be expanded as was said -> so it's not so serious problem
moving opened issues from TM <= 6.1 to TM=Dev
*** Issue 144385 has been marked as a duplicate of this issue. ***
Marek, these are yours now ...
The first use case is incorrect uncompilable code. We can support correct code ie. IMO WONTFIX. Second case from Vita when first fold ends on the same line where second starts work fine now even if there is no fold/unfold button/annotation for second fold. It is possible to unfold second fold by double click on folded box of second fold. Definitely it is better to avoid such situation.