all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Overlay-related TODO
@ 2016-04-26 21:59 Vladimir Kazanov
  2016-04-26 23:46 ` John Wiegley
  2016-04-27  6:38 ` Eli Zaretskii
  0 siblings, 2 replies; 7+ messages in thread
From: Vladimir Kazanov @ 2016-04-26 21:59 UTC (permalink / raw)
  To: emacs-devel@gnu.org

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Overlay-related TODO
  2016-04-26 21:59 Overlay-related TODO Vladimir Kazanov
@ 2016-04-26 23:46 ` John Wiegley
  2016-04-27  6:38 ` Eli Zaretskii
  1 sibling, 0 replies; 7+ messages in thread
From: John Wiegley @ 2016-04-26 23:46 UTC (permalink / raw)
  To: Vladimir Kazanov; +Cc: emacs-devel@gnu.org

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Overlay-related TODO
  2016-04-26 21:59 Overlay-related TODO Vladimir Kazanov
  2016-04-26 23:46 ` John Wiegley
@ 2016-04-27  6:38 ` Eli Zaretskii
  2016-04-27 11:40   ` Vladimir Kazanov
  2016-04-27 19:03   ` John Wiegley
  1 sibling, 2 replies; 7+ messages in thread
From: Eli Zaretskii @ 2016-04-27  6:38 UTC (permalink / raw)
  To: Vladimir Kazanov; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Overlay-related TODO
  2016-04-27  6:38 ` Eli Zaretskii
@ 2016-04-27 11:40   ` Vladimir Kazanov
  2016-04-27 12:56     ` Stefan Monnier
  2016-04-27 19:03   ` John Wiegley
  1 sibling, 1 reply; 7+ messages in thread
From: Vladimir Kazanov @ 2016-04-27 11:40 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Overlay-related TODO
  2016-04-27 11:40   ` Vladimir Kazanov
@ 2016-04-27 12:56     ` Stefan Monnier
  0 siblings, 0 replies; 7+ messages in thread
From: Stefan Monnier @ 2016-04-27 12:56 UTC (permalink / raw)
  To: emacs-devel

> 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




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Overlay-related TODO
  2016-04-27  6:38 ` Eli Zaretskii
  2016-04-27 11:40   ` Vladimir Kazanov
@ 2016-04-27 19:03   ` John Wiegley
  2016-04-28 20:09     ` Vladimir Kazanov
  1 sibling, 1 reply; 7+ messages in thread
From: John Wiegley @ 2016-04-27 19:03 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Vladimir Kazanov, emacs-devel

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Overlay-related TODO
  2016-04-27 19:03   ` John Wiegley
@ 2016-04-28 20:09     ` Vladimir Kazanov
  0 siblings, 0 replies; 7+ messages in thread
From: Vladimir Kazanov @ 2016-04-28 20:09 UTC (permalink / raw)
  To: Eli Zaretskii, emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2016-04-28 20:09 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-04-26 21:59 Overlay-related TODO Vladimir Kazanov
2016-04-26 23:46 ` John Wiegley
2016-04-27  6:38 ` Eli Zaretskii
2016-04-27 11:40   ` Vladimir Kazanov
2016-04-27 12:56     ` Stefan Monnier
2016-04-27 19:03   ` John Wiegley
2016-04-28 20:09     ` Vladimir Kazanov

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.