>
> The interest in improving the implementation of overlays to gain
> better scalability, speed, and additional features -- is still there.
> As for "helping", you will have to be more explicit in what kind of
> help you'd like to have. E.g., is it just with discussions, or do you
> need help in coding as well?
What I want is to discuss possible approaches to the problem, I can handle the code myself :-)
>> 2. Who can I discuss the possible solution with..?
>
> Us. Here. If you have a specific design in mind, just describe it.
>
> I think one of the first jobs (not necessarily done by you) should be
> a suite of tests that exercise the functionality and also present the
> current performance of typical expensive and inexpensive tasks related
> to overlays. This will be instrumental in both guiding the design and
> implementation, and in testing the improvements brought by the new
> code.
Sure, the first step would be to introduce proper tests.
The easier thing to do might be to introduce a balanced tree for overlays specifically. Overlays being basically just point pairs then can be represented as (left point, length) pairs, as described in Cormen et al, 14.3. Having a specialized tree also simplifies things for me personally: I don't have to tinker with code related to text property interval trees.
I believe that Stefan had something else in mind. As much as I understood he wanted to reuse the text property interval tree. I might have misunderstood something, but this would basically turn overlays into special text properties of sorts, and current overlay-related interface would be a bit harder to implement. Also, interval-handling code is all over textprop.c/interval.[ch]/buffer.c, and adding overlays on top of that does not sound all that reasonable to me.
Again, I might have just misunderstood something.
What do people here think about both approaches..?
Thanks,
Vlad