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.
It would be nice to support defaultstate="expanded" to be able to expand some parts of code by default. Like in this example for collapsed code: // <editor-fold defaultstate="collapsed"> Your code goes here... // </editor-fold> Thanks in advance.
I don't quite understand the use-cases. Do you suppose that code will be collapsed by default (e.g. all methods) and the user would force expansion of a specific method using such a comment ?
(In reply to comment #1) > I don't quite understand the use-cases. Do you suppose that code will be > collapsed by default (e.g. all methods) and the user would force expansion of a > specific method using such a comment ? Actually I'm not using this feature but I reported that since it sounds reasonable to me what she (CCed hlupec) complains about... It's exactly as you wrote. You are in the PHP and all methods are collapsed by default. You are using object oriented design so your class handles many basic things which mustn't be often changed together with some frequently used method like #createMenu(). So since you are working in 80% on that one method, it would make sense to have only this one expanded.
A question - what approach better satisfies the scenario: a marker in the source, as requested in comment #1 (versioned, affects all users), or an invisible marker = persisted folding state (not versioned with file, affects just single user) ?
Hmmmm, it's hard to choose:) Your idea with persisted folding state is also good, but for my purposes the alternative of <editor-fold defaultstate="collapsed"> is good enough. I think it's also easier to implement:)
(In reply to hlupec from comment #4) > Hmmmm, it's hard to choose:) Your idea with persisted folding state is also > good, but for my purposes the alternative of <editor-fold > defaultstate="collapsed"> is good enough. I think it's also easier to > implement:) Currently <editor-fold> creates a new fold and defines its state. In order to satisfy your scenario I think the <editor-fold> needs to alter other fold's state (the one created for a method/function/inner class, ...) -- this is not supported at the moment. Similar API would be useful to read fold state from some preferences for the persistent folding feature. But you're right - at least the implementors do not need to invent some fold monikers/IDs :) in order to save their state.
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss
It's not a bug but a feature request and as far as I know it's not implemented yet ;)