Overlay-related TODO

Overlay-related TODO

[Vladimir Kazanov]

Hello, emacs devs!

Some time ago me and Stefan discussed possible changes to the way
overlays work (see
https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00616.html).
Unfortunately, I didn't find the time required back then, but I do
have it now.

I checked the TODO - Stefan's thoughts are still there (grep for "Move
overlays"), I also checked the code - overlays still use the very same
linked lists.

I've spent a couple of evenings reading the code around intervals,
text properties and overlays, and I think I have general understanding
of changes required.

So, my questions are:

1. Stefan is not a maintainer now. Is current maintainer interested in
helping me to improve overlays..?

2. Who can I discuss the possible solution with..?

Thank you,
Vlad

Re: Overlay-related TODO

[John Wiegley]

>>>>> Vladimir Kazanov <vekazanov@gmail.com> writes:

> 1. Stefan is not a maintainer now. Is current maintainer interested in
> helping me to improve overlays..?

I would love to see overlays improved, but I'm not as much of a "coding"
maintainer as Stefan was.

> 2. Who can I discuss the possible solution with..?

Your best bet is just to ask and discuss here, which you've done, so you
should start receiving responses shortly. :)

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Overlay-related TODO

[Eli Zaretskii]

> From: Vladimir Kazanov <vekazanov@gmail.com>
> Date: Tue, 26 Apr 2016 22:59:03 +0100
> 
> 1. Stefan is not a maintainer now. Is current maintainer interested in
> helping me to improve overlays..?

The interest in improving the implementation of overlays to gain
better scalability, speed, and additional features -- is still there.
As for "helping", you will have to be more explicit in what kind of
help you'd like to have.  E.g., is it just with discussions, or do you
need help in coding as well?

> 2. Who can I discuss the possible solution with..?

Us.  Here.  If you have a specific design in mind, just describe it.

I think one of the first jobs (not necessarily done by you) should be
a suite of tests that exercise the functionality and also present the
current performance of typical expensive and inexpensive tasks related
to overlays.  This will be instrumental in both guiding the design and
implementation, and in testing the improvements brought by the new
code.

Thanks.

Re: Overlay-related TODO

[Vladimir Kazanov]

[-- Attachment #1: Type: text/plain, Size: 1956 bytes --]

Hi Eli, John,

thanks for answering!

>
> The interest in improving the implementation of overlays to gain
> better scalability, speed, and additional features -- is still there.
> As for "helping", you will have to be more explicit in what kind of
> help you'd like to have.  E.g., is it just with discussions, or do you
> need help in coding as well?

What I want is to discuss possible approaches to the problem, I can handle
the code myself :-)

>> 2. Who can I discuss the possible solution with..?
>
> Us.  Here.  If you have a specific design in mind, just describe it.
>
> I think one of the first jobs (not necessarily done by you) should be
> a suite of tests that exercise the functionality and also present the
> current performance of typical expensive and inexpensive tasks related
> to overlays.  This will be instrumental in both guiding the design and
> implementation, and in testing the improvements brought by the new
> code.

Sure, the first step would be to introduce proper tests.

The easier thing to do might be to introduce a balanced tree for overlays
specifically. Overlays being basically just point pairs then can be
represented as (left point, length) pairs, as described in Cormen et al,
14.3. Having a specialized tree also simplifies things for me personally: I
don't have to  tinker with code related to text property interval trees.

I believe that Stefan had something else in mind. As much as I understood
he wanted to reuse the text property interval tree. I might have
misunderstood something, but this would basically turn overlays into
special text properties of sorts, and current overlay-related interface
would be a bit harder to implement. Also, interval-handling code is all
over textprop.c/interval.[ch]/buffer.c, and adding overlays on top of that
does not sound all that reasonable to me.

Again, I might have just misunderstood something.

What do people here think about both approaches..?

Thanks,
Vlad

[-- Attachment #2: Type: text/html, Size: 2270 bytes --]

Re: Overlay-related TODO

[Stefan Monnier]

> I believe that Stefan had something else in mind. As much as I understood
> he wanted to reuse the text property interval tree. I might have
> misunderstood something, but this would basically turn overlays into
> special text properties of sorts, and current overlay-related interface
> would be a bit harder to implement. Also, interval-handling code is all
> over textprop.c/interval.[ch]/buffer.c, and adding overlays on top of that
> does not sound all that reasonable to me.

> Again, I might have just misunderstood something.

> What do people here think about both approaches..?

Both approaches have advantages and disadvantages.  Obviously, I think
re-using the intervals tree will have more advantages and fewer
disadvantages, but I can't see any obvious reason why we'd reject
a patch which uses your approach.

BTW, regarding the issue of testing, the way I'd try to do it is by
keeping adding the new implementation without removing the old one, and
adding assertions that check the new code returns the same answers as
the old one.


        Stefan

Re: Overlay-related TODO

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> I think one of the first jobs (not necessarily done by you) should be a
> suite of tests that exercise the functionality and also present the current
> performance of typical expensive and inexpensive tasks related to overlays.
> This will be instrumental in both guiding the design and implementation, and
> in testing the improvements brought by the new code.

+1

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Overlay-related TODO

[Vladimir Kazanov]

[-- Attachment #1: Type: text/plain, Size: 743 bytes --]

Stefan, John, Eli,

okay, thank you, I'll see what I can do here :-)

Vlad

On Thu, Apr 28, 2016 at 5:57 PM John Wiegley <jwiegley@gmail.com> wrote:

> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
>
> > I think one of the first jobs (not necessarily done by you) should be a
> > suite of tests that exercise the functionality and also present the
> current
> > performance of typical expensive and inexpensive tasks related to
> overlays.
> > This will be instrumental in both guiding the design and implementation,
> and
> > in testing the improvements brought by the new code.
>
> +1
>
> --
> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
>

[-- Attachment #2: Type: text/html, Size: 1211 bytes --]