Re: Overlays as an AA-tree

[Joakim Jalap]

Stefan Monnier <address@hidden> writes:

>> And here I thought it was rather an elegant solution :) (to the problem
>> of one overlay's beg going past another's because of an insert).
>
> It doesn't solve the problem of updating the tree after
> a deletion (where some overlays may suddenly end up at the same place,
> so the tree will also need some amount of reorganization).

But an overlay can't *pass* another because of a delete, so I think that
case is OK.

>> What's a better way? When adjusting for an insert at an overlay with
>> front-advance non nil, first delete it from the tree, then
>> reinsert it?
>
> The way I look at it, there's no good reason to try and be very clever:
> whenever the text is modified somewhere, remove all the overlays whose
> end points fall within (or on the edge of) the change, and then
> re-insert them.

This sounds very expensive to me, theres quite a lot of rebalncing going
on at insertion/deletion. But maybe that isn't a problem.

-- Joakim