From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Vladimir Kazanov Newsgroups: gmane.emacs.devel Subject: Re: Overlay-related TODO Date: Wed, 27 Apr 2016 11:40:18 +0000 Message-ID: References: <83fuu7zhd4.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=e89a8f50379851a7f1053175e0fe X-Trace: ger.gmane.org 1461757238 16850 80.91.229.3 (27 Apr 2016 11:40:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Apr 2016 11:40:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 27 13:40:37 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1avNpc-0004rw-Ka for ged-emacs-devel@m.gmane.org; Wed, 27 Apr 2016 13:40:36 +0200 Original-Received: from localhost ([::1]:42658 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1avNpc-0006PR-0i for ged-emacs-devel@m.gmane.org; Wed, 27 Apr 2016 07:40:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48298) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1avNpW-0006NH-7z for emacs-devel@gnu.org; Wed, 27 Apr 2016 07:40:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1avNpV-00066P-4m for emacs-devel@gnu.org; Wed, 27 Apr 2016 07:40:30 -0400 Original-Received: from mail-lf0-x232.google.com ([2a00:1450:4010:c07::232]:34669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1avNpU-000666-Op; Wed, 27 Apr 2016 07:40:29 -0400 Original-Received: by mail-lf0-x232.google.com with SMTP id j11so52909896lfb.1; Wed, 27 Apr 2016 04:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SxJ/Y9zxWhj7hXLgKiVjMOuDn5n5kCt1nsfIqLCzbm4=; b=vkFzTq79836SYfnsAhykhQDDtqBvCXEuwYAWw/xWSMZnbGgRRQHXQKXfRDI95GcSLR LwReKEsYOq4SHUqxBYcR+Ny5WbiHFFF938bl3iw6NAsCMK//7PBn8l9riWJmQRIwthn1 jYlax22unQcCBpEJdH9AoLDQs8s+edZdT/U9ulmGcN0bJ2hygeLz/BJ8h1OqqCy3yAIz 0Y1QW/jIi61oQxHueoIZkqFQd5toiYPg+rkUj7ybDVuJUbDu9I4XX347qk5olwzIsLu1 WllxbvZl1fbAA/gG4q1ZvVuf6nz4WOnC78Y48bZiSuGZ+7MwLDfnBdoRZJsJ+3e7sg47 xz7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SxJ/Y9zxWhj7hXLgKiVjMOuDn5n5kCt1nsfIqLCzbm4=; b=OXixtjAdVxgDVwMswppkPNPNY1HFKmJwo2c2E+E0Oz+27YZEF2N1F50GThW9tJDBUZ pRkb6yPCAal+OrlyEQ+xdycXEy4Tu6SGWG1Qd2YMMtszEQyOqMReGoL+Vhrief4iwxsJ HYYcS7f3F/JAp3X3+rdWo2MmCPio765YFnztM+GY/eXaBYFBXLSjB/+hIRBRREdnnWyn +N/zdHaneVwWN0wuUMpbYBljgg1q6pREwYQpQNRjTyTnvwR2ftZKodkC/TqL0ERyDLAi Z3U9mPyj00cGrimF3yJsoWBssz4IQHlrKQc2R+OzgDErh1L7NMmxlVTcO+wTXZ37hM+T uVUQ== X-Gm-Message-State: AOPr4FWdOy1TrvboNosNzYsbq/iivIMxakvytNlEG7MzEl1DQIrm9uKs1MVuuCe/KywpzvDa+AXs4KEhoOWOUQ== X-Received: by 10.112.61.39 with SMTP id m7mr3467661lbr.72.1461757227934; Wed, 27 Apr 2016 04:40:27 -0700 (PDT) In-Reply-To: <83fuu7zhd4.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c07::232 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:203385 Archived-At: --e89a8f50379851a7f1053175e0fe Content-Type: text/plain; charset=UTF-8 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 --e89a8f50379851a7f1053175e0fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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.<= br> > As for "helping", you will have to be more explicit in what = kind of
> help you'd like to have.=C2=A0 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 :-)=C2=A0

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

Sure, the first step would be to i= ntroduce proper tests.

The easier thing to do might be to introduce a balanced tree for overla= ys specifically. Overlays being basically just point pairs then can be repr= esented 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&#= 39;t have to =C2=A0tinker with code related to text property interval trees= .

I believe that Stefan had something else in mind. As m= uch as I understood he wanted to reuse the text property interval tree. I m= ight have misunderstood something, but this would basically turn overlays i= nto special text properties of sorts, and current overlay-related interface= would be a bit harder to implement. Also, interval-handling code is all ov= er textprop.c/interval.[ch]/buffer.c, and adding overlays on top of that do= es not sound all that reasonable to me.=C2=A0

Again, I might have ju= st misunderstood something.

What do people here think about both app= roaches..?

Thanks,=C2=A0
Vlad
--e89a8f50379851a7f1053175e0fe--