Re: Overlays as an AA-tree

[Eli Zaretskii]

> From: Joakim Jalap <address@hidden>
> Date: Tue, 20 Sep 2016 12:32:28 +0200
> 
> I've been working on an item from /etc/TODO on and off for a while now,
> but now I have hit a bit of a roadblock.

Thanks for working on this TODO item.

> I got a bit on the way; I managed to get the tree structure in place and
> to make it work for some very simple cases. I wrote some simple ert tests
> for this. The idea was to be able to compile in three ways: just as
> before, with just the new overlay implementation and with both
> implementations and a whole lot of easserts. But alas, it turned out to
> be too hard for me. There's quite a bit of fiddly code regarding
> overlays and ripping it out and replacing it seems to be more than I can
> chew. So the status right now is that nothing works... If you define
> BOTH_OVERLAYS it will compile but fail an eassert at startup, if you
> define NEW_OVERLAYS it doesn't even compile, since there's some stuff I
> haven't replaced properly.
> 
> Anyway, I basically have two questions for you experts:
> 1) Is it worth continuing down this path?
> 2) If so, what's the best way to go about something like this? Replacing
> the whole thing at once seems very hard, but I don't really know how to
> go about replacing it little by little.
> 
> I'm attaching the diff. It is an unholy mess of ifdefs, but the meat of
> it is in overlays.[ch] and buffer.c. It is a pretty big diff, and it's
> based on master from a few months ago, so I'm not even sure it applies,
> but I'd be grateful if somebody could have a quick look at it and try to
> see if there's anything worth keeping there. If there's any interest I
> could try rebasing it.

It seems like you only attached part of the changes, because all I see
in the attachment is 3 entirely new files, with no ifdef's anywhere in
sight.  So I couldn't look at the problems that got you stuck.

Just by reading your description, I don't think I understand the
nature of your difficulties.  Overlays present a relatively small
number of Lisp-visible APIs, so all you need is to re-implement those
few APIs based on the new internal representation.  What exactly gives
you trouble with that?  (I see you've implemented new APIs, but that
doesn't have to be part of the job, it's up to you.)

As for the migration path: if you find it difficult to keep the old
code, just remove it.  When your code is ready for testing by others,
you could push a public Git branch and ask people to check it out.  We
won't merge the branch to master until it is stable enough, so the
fact that the old implementation will be gone is not a problem.  (If
needed, we can always compare with older versions to see if some issue
is due to the new implementation or not.)

You say that replacing it all is very hard, but I don't really
understand why.  Please elaborate.

Thanks again for your efforts.  Please keep up the good work.