I told myself I’d never do it, and it’s a feature I personally never use. Some people agree with me, as evidenced by the second hit on Google for “code folding.” Still, lots of people like it, and so in an effort to make RSyntaxTextArea as robust as possible, I’ve begun exploring code folding:
Nothing is checked into Subversion yet, but I’ve taken the first baby step. Folding is done by a FoldParser interface implementation, so languages with differing ideas of what a “foldable region” is can be accommodated. A “CurlyFoldParser” implementation will be available by default, that simply identifies foldable regions by curly braces (seen above). This should be sufficient for the many languages out there with C-like syntax. I already have several ideas to allow for easy extensibility as well, as far as fold parsing is concerned.
The FoldParser for a text area is called after a short time of no edits, similar to other RSTA Parser implementations, such as the built-in TaskTagParser and the SpellChecker add-on. Folds are re-evaluated, and the fold indicator in the gutter is updated if necessary.
Of course, there are all kinds of crazy edge cases you never think about until you start implementing something – two or more folds starting on the same line, one fold starting on a line in which another ends, etc. I’m looking into how other editors handle such cases, and you’d be surprised how sometimes they aren’t as well-behaved as you’d expect (which is good for me, as I can copy their behavior and say things like “Well, Eclipse behaves like that!”).
In any case, this means that I’ll need folks willing to beta-test this feature before it’s included in an “official” RSTA release. If you’re a user of RSyntaxTextArea and are ga-ga about code folding, please let me know and we’ll work together to make sure this feature is as bullet-proof as possible!