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.
Created attachment 131623 [details] Proposed changes This API change attempts to support several enhancements for extending fold types. It also adopts patterns found in fold providers (java, csl) to the base API, which should simplify the FoldManager implementations. For more details/overview of the change, please see wiki: http://wiki.netbeans.org/CodeFoldingChanges201302 The attached changeset is cummulative with changes proposed for the issues dependent (changes in editor mime lookup, settings, ...).
Svato, not sure if I understand everything correctly, but does this affect existing CSL clients somehow? I mean with the new API is there a better/new/easier way how to implement fold management for certain CSL languages different than implementing StructureScanner.fold() method?
Sorry; I'll extend the wiki page with CSL explanation. API for CSL clients is NOT affected (formally), and if the CSL-based module remains unchanged, nothing happens. But if a FoldType is registered (using the new APIs) with 'code' property that match the CSL fold type (key in map returned by SS.fold()) - that FoldType will be used to construct folds. So if a CSL-based language registers its FoldTypes, UI for auto-folding will appear for that language, the placeholder text (in FoldTemplate) can be defined, and ContentReader (for variable placeholder text) can be registered. The "good" news is that the diff contains already adjustments for PHP and HTML. JS should be easy, too.
(In reply to comment #2) > Sorry; I'll extend the wiki page with CSL explanation. API for CSL clients is > NOT affected (formally), and if the CSL-based module remains unchanged, nothing > happens. Awesome, thanks.. > But if a FoldType is registered (using the new APIs) with 'code' property that > match the CSL fold type (key in map returned by SS.fold()) - that FoldType will > be used to construct folds. > > So if a CSL-based language registers its FoldTypes, UI for auto-folding will > appear for that language, the placeholder text (in FoldTemplate) can be > defined, and ContentReader (for variable placeholder text) can be registered. > > The "good" news is that the diff contains already adjustments for PHP and HTML. > JS should be easy, too. Thanks for the explanation, it looks great from the CSL client perspective. Just one detail. MJ01: Could we make the FoldTypeProvider.getValues() method parametrized? I imagine something like this: public Collection<FoldType> getValues(Class<? extends FoldType> type); ..with such change we could avoid type checks in FoldTypeProvider implementations (e.g. in PHPFoldingProvider we could just return TYPES instead of "return type == FoldType.class ? TYPES : null;") As an impact we would have to make FoldRegistry enumType property parametrized as well, but that's just a cosmetic change.
Re. MJ01: good catch. The method Collection getValues(Class t); is what remains from generalized concept of extensible enums. I suspect that for purposes of CSL, more such enums will be defined (i.e. modifiers, element kinds), and there could be an uniform mechanism EnumValueProvider; I wanted to allow multiple enums to be served from one implementation class, that's why the Class parameter is there, and the method is not generified. It could prevent module owners from writing 2-3 classes similar to each other, each serving a different enum. At this point, though it is a speculative generalization = not a good API. I didn't find a reasonable alternative how to bridge FoldTypeProviders to the supposed generic ext.enumeration; please suggest ;)
Implemented in changeset http://hg.netbeans.org/jet-main/rev/2826899460ad Implied changes in individual languages will follow in a separate changeset.
CSL support in http://hg.netbeans.org/jet-main/rev/2201d4aea94e Java support in http://hg.netbeans.org/jet-main/rev/cd37962eaf3c
Integrated into 'main-golden', will be available in build *201303122300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/c1b657407e68 User: Svata Dedic <sdedic@netbeans.org> Log: #226413, #226368: Folds UI separated to a new module. editor.lib partially cleaned up from folding code.
Integrated into 'main-golden', will be available in build *201303132300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/2826899460ad User: Svata Dedic <sdedic@netbeans.org> Log: #226413: Fold API enhancements implemented
*** Bug 216456 has been marked as a duplicate of this bug. ***