Hi Eli, John, thanks for answering! > > 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