Re: Overlays as an AA-tree

[Joakim Jalap]

Eli Zaretskii <address@hidden> writes:

> If you use markers, they move automatically, so I'm unsure what you
> needed to reimplement.  What am I missing?

As Stefan wrote in an earlier mail, the problem is that the tree needs
to be rebalanced when a node changes, so there will have to be code to
deal with these movements anyway. Although I guess it would be possible
to have all the markers moved the 'usual' way, and then rebalance the
tree after that.

Also, in Stefan's original suggestion (this is all his idea really) the
plan was to later replace markers by a 'degenerate overlay' of length 0,
and make use of the same tree structure. That is of course out of scope
of this, but something I had in mind nonetheless.

> AFAIR, xdisp.c will be perfectly happy if there are no overlays in
> sight in a buffer, so just making the bunch of APIs it uses to access
> overlays be no-ops should allow you to continue past the display
> engine part of the puzzle.  (Not sure what you meant by buffer.c,
> since that is where the current overlay implementation lives.)

Of course! Thank you. I never thought of that.

What I meant in buffer.c are the non-Lisp-visible functions, like for
example evaporate_overlays.

> In any case, I know what you mean by "until everything works nothing
> really works".  Been there, done that.  My advice is to take this
> pragmatically, and basically let Emacs guide your progress.
> Specifically, write whatever you think should be "enough", get it to
> compile, then start Emacs under a debugger.  If/when it crashes,
> investigate the crash, fix it (which might require to implement
> something you didn't before, or it might require deleting some code no
> longer needed with the new implementation), then continue to the next
> crash.  Eventually you will get to a point where Emacs starts, but
> maybe some parts of display don't look right; debug and fix that as
> well.  Finally, you get to the point where "emacs -Q" somes up and
> looks OK, so you can begin implementing and testing the features in
> the order you want.

Right. I was trying to keep all old functionality, but as you point out,
I guess nothing in Emacs really *needs* overlays to be displayed. So
maybe I can make no-ops of most of the functions which get overlays and
so on.

>> 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.
>
> If it's hard, don't do that.  There's no requirement to keep the old
> code available.

No, I'll probaly give up on that idea.

> See above for one suggestion, something I used successfully in my own
> Emacs projects of similar magnitude.

Thanks. I'll try just removing all the old code.