From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Overlays as an AA-tree Date: Wed, 21 Sep 2016 19:14:51 +0300 Message-ID: <83fuotfcw4.fsf@gnu.org> References: <87d1jylv43.fsf@fastmail.com> <838tumhbx1.fsf@gnu.org> <87lgymjxz1.fsf@fastmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1474474715 22271 195.159.176.226 (21 Sep 2016 16:18:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 21 Sep 2016 16:18:35 +0000 (UTC) Cc: emacs-devel@gnu.org To: Joakim Jalap Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 21 18:18:31 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bmkDw-0003Ym-L0 for ged-emacs-devel@m.gmane.org; Wed, 21 Sep 2016 18:18:16 +0200 Original-Received: from localhost ([::1]:43664 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmkDt-0002qW-T3 for ged-emacs-devel@m.gmane.org; Wed, 21 Sep 2016 12:18:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmkAV-00084i-7q for emacs-devel@gnu.org; Wed, 21 Sep 2016 12:14:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bmkAQ-00052V-3Q for emacs-devel@gnu.org; Wed, 21 Sep 2016 12:14:42 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39335) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmkAQ-00052P-0y; Wed, 21 Sep 2016 12:14:38 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3798 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bmkAO-0001uu-DU; Wed, 21 Sep 2016 12:14:37 -0400 In-reply-to: <87lgymjxz1.fsf@fastmail.com> (message from Joakim Jalap on Tue, 20 Sep 2016 19:13:38 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:207664 Archived-At: > From: Joakim Jalap > Cc: emacs-devel@gnu.org > Date: Tue, 20 Sep 2016 19:13:38 +0200 > > > 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. If you use markers, they move automatically, so I'm unsure what you needed to reimplement. What am I missing? 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.) 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. > > 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. If it's hard, don't do that. There's no requirement to keep the old code available. > 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. See above for one suggestion, something I used successfully in my own Emacs projects of similar magnitude. Thanks.