[prev in list] [next in list] [prev in thread] [next in thread] 

List:       nedit-develop
Subject:    Re: Folding: Maximum size of folded regions--influence on back end
From:       Randy Kramer <rhkramer () gmail ! com>
Date:       2008-04-06 13:36:49
Message-ID: 200804060936.51767.rhkramer () gmail ! com
[Download RAW message or body]

On Sunday 06 April 2008 04:23 am, Bert Wesarg wrote:
> On Sat, Apr 5, 2008 at 11:45 PM, Randy Kramer <rhkramer@gmail.com> wrote:
> >  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.
> If this really influences the back end design, IMHO the design is Just
> Plain Wrong.
> 
> I don't see any reason why there are such limits like maximum size of
> folded region, maximum number of folded regions, maximum number of
> nested folds.

Well, I really didn't mean maximum size of folded regions (as in a limit), I 
was more trying to give an order of magnitude of sizes to consider tradeoffs 
like brute force methods vs. smarter methods.  

If we use one particular brute force method, for example, to find the next 
visible character by searching through all of the possible folded characters 
that could be in-between, sometimes we may search through 80,000 characters 
or more, other times we may search through, I'm guessing, 10.

Maybe for c code the brute force approach would always be reasonable.  I don't 
know at what point the crossover would be between brute force and smarter 
methods.  It is something that may have to be considered at some point.

Or, say it another way--from my point of view (with my limited knowledge of c 
and the NEdit codebase), I would tend to favor simple solutions (simple to 
code and to integrate into the existing NEdit design)--those would tend to be 
brute force methods.  I don't know enough at this point whether to rule those 
out or not.  (And, such brute force methods might be faster than smarter 
methods when skipping over short spans of folded text (for some value of 
short spans of text.)

Anyway, like I said, I wondered if we all had the same vision of how much text 
might have to be hidden.

Randy Kramer

-- 
NEdit Develop mailing list - Develop@nedit.org
http://www.nedit.org/mailman/listinfo/develop
[prev in list] [next in list] [prev in thread] [next in thread]