Re: [ jEdit-devel ] Enhancing Folding

[Tom L. <ts...@uk...>]

At 16:41 02/05/2001 Wednesday +1000, you wrote:
>On Tue, May 01, 2001 at 09:46:29AM +0100, Tom Locke wrote:
> > Can you explain your thinking about fold objects a bit more. If I return a
> > new fold object, what is the Buffer going to do with it.
>
>I really have not thought about this much. Fold objects will somehow
>be created and deleted by FoldHandlers, and stored in the buffer.
>Then, each text area could have a hash of visible and invisible folds
>(rather than maintaining a list of visible lines for each text area).

OK - this is pretty much what Ripple does, the fold objects are stored in 
the document, in such a way that they automatically move around as lines 
are added and removed. As we were discussing a while back, I think they 
should be stored in the lineInfo array within the buffer.

I'd like to suggest an alternative to the FoldHandler:

interface FoldHandler {

         // return the fold object for a given line, or null for a plain line
         public FoldObject getFoldObject(Buffer buffer, int line);

}

In other words - rather than asking what the fold level is, ask if this is 
a fold start/end or just a plain line. To tell if it's a fold start or fold 
end:

class/interface FoldObject {

         // Each fold object represents either a fold start or fold end
         public boolean isFoldEnd()

}

It might be possible to use share a single instance for every fold end.

> > With explicit fold demarcation. The fold level can change without the line
> > itself changing at all, so the cacheing strategy will have to be more
> > sophisticated than this. If the fold manager can be notified whenever fold
> > comments are modified, it can maintain this fold level information very
> > cheaply, so cahceing is probably not needed at all. I think cacheing 
> should
> > be the responsibility of the FoldHandler, rather than being in the core.
> > Indent based folding could use the cacheing scheme you suggest, other
> > styles have their own kinds of cache.
>
>There of course would be an invalidateFoldLevels(int start, int end)
>method or similar.

Is this a Buffer method? Isn't easier just to leave the cacheing to the 
FoldHandler?

> > There's no easy way to fix this - the broken fold comment could be 
> anywhere
> > inside the method, which could of course be a lot bigger, with many more
> > inner folds. Also think about the fold objects - lines 6, 7 and 8 have 
> just
> > changed fold.
>
>I would say this is something the user will just have to live with
>for now. Making it handle every single corner case would just make
>the code bloated and unreadable. I'd rather keep it simple and
>maintainable.

What if I wanted to implement something along these lines as a plugin? Can 
my plugin listen to document edit events?

>I'm planning on adding this, along with a 'stack' of narrowed folds
>and a fold navigator (perhaps we can reuse some code from Ripple?)

Great - I'd be happy to port the Ripple fold browser to jEdit, but the way 
it interacts with jEdit is likely to be quite different, and once you 
remove that stuff, it's not much more than a JTree (with some cool 'instant 
tooltips' when the fold comment is wider than the window :-)

Tom.