emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Overlays as an AA-tree


From: Joakim Jalap
Subject: Re: Overlays as an AA-tree
Date: Tue, 20 Sep 2016 19:13:38 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

> 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.

Yes, sorry. Attaching the full diff.

> 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.)

Well, the Lisp-visible APIs weren't really the problem. The problem was
more in the 'internal' handling of overlays in buffer.c and in xdisp.c,
and also the fact that I had to reimplement a lot of the logic about how
markers are moved when the buffer changes. Speaking of which, is the
byte position stored in a marker of any significance in an overlay?
Otherwise I could at least get rid of those.

I don't really think it's anything that's monumentally difficult, it's
more that until everything works nothing really works, so I can't even
get Emacs to start.

The DEFUNs I added in overlays.c were just for my own debugging purposes
while writing the code, it's nothing I intended to keep.

> 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.

Well, first of all I thought it would be a good strategy to keep all the
old code so that I could compare the results at runtime, but that turned
into a huge mess of ifdefs.

Secondly I thought that it'd be slightly easier to iterate while keeping
the old code, but that turned out to be harder than I first imagined.

Basically my problem is that when I throw the old code out wholesale,
suddenly that's thousands of lines I have to write which have to
somewhat work, or I can't even get Emacs to build, let alone start up,
so it turns into quite a big project, which I don't really see how I can
break up into smaller parts.

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

Thanks! I'll keep working on it :)

Attachment: new-diff.diff
Description: Complete diff


reply via email to

[Prev in Thread] Current Thread [Next in Thread]