Re: noverlay branch

[Stefan Monnier]

>> Of the rest, item 1 sounds like the most important one, but do you
>> have ideas for how to achieve that?
> I think (3) -- improving the comments -- is a good starting point,

Not only that.  It's an important end in itself.
Even if you don't know what the code does or why it does something,
writing it as a comment can be very useful (can help someone else, who
does understand the code, notice that it deserves an explanation).

> My idea is: store each overlay in two trees, one ordered by ascending
> BEG and one ordered by descending END.  These are the similar to the
> current "overlays before" and "overlays after" linked lists, except that
> the "overlay center" is gone and replaced by O(log N) lookups.  (In fact
> we could retain the idea of an "overlay center" by maintaining a
> "finger" node in each tree...but I digress...)

I don't want to discourage you, but please do remember that we have
lived with a "ridiculously inefficient" implementation for the last 30
years or so, and that keeping two trees comes at a cost
(coding/maintenance cost + runtime cost + heapsize cost).


        Stefan