Folding: Maximum size of folded regions--influence on back end design for folding?

[Randy Kramer]

I don't know if we need to discuss this yet, but in some of my recent thinking 
I recognize the possibility for a difference in approach to folding depending 
on how big the size of folded regions might be.  So:

   * I have a number of use cases for folding, but one of them involves entire 
books in a single nedit file, and folding that file down so that the only 
things visible are the book title and the chapter titles.  In this case, the 
size of a fold could reach what?  80 KB?  (Just a guess, based on possibly 40 
pages in a chapter and 2000 characters per page--maybe I need to do some  
checking to see some chapter sizes in real life.)  (Of course there are 
folding regions within those (headings and subheadings within chapters) that 
are much smaller.)

   * On the other hand, in current cases of folding of code (for example c 
files) (and I'm thinking about how c code is currently folded in kate), most 
folds would be much smaller, like the size of a single function--what might 
that be--I know people talk about functions not exceeding one page (or 
screen), but they do--maybe a realistic typical maximum might be on the order 
of 12 KB (based on 200 lines of code averaging 60 characters per line).

Aside: I'm hoping to fold C (and other) code down to be much smaller than 
that--I'd like to be able to easily fold code down to see a heading for the 
includes, a heading for declarations, (maybe a few similar things I'm not 
thinking about yet) and a heading for each function in a file.

Anyway, back to the point--I guess there could be about one order of magnitude 
difference in the size of expected folds depending on the use--I guess that 
could influence the back end design for folding.

I guess my main reason for bringing this up is as food for thought and to try 
to make sure we're all on the same page.

Randy Kramer