From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Joakim Jalap Newsgroups: gmane.emacs.devel Subject: Re: Overlays as an AA-tree Date: Thu, 22 Sep 2016 12:35:16 +0200 Message-ID: <874m58p69r.fsf@fastmail.com> References: <87d1jylv43.fsf@fastmail.com> <838tumhbx1.fsf@gnu.org> <87lgymjxz1.fsf@fastmail.com> <83fuotfcw4.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1474541867 21689 195.159.176.226 (22 Sep 2016 10:57:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 22 Sep 2016 10:57:47 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 22 12:57:42 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 1bn1gw-0002oW-VY for ged-emacs-devel@m.gmane.org; Thu, 22 Sep 2016 12:57:28 +0200 Original-Received: from localhost ([::1]:38333 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bn1gv-0002ml-Bt for ged-emacs-devel@m.gmane.org; Thu, 22 Sep 2016 06:57:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57529) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bn1QR-0007W9-8J for emacs-devel@gnu.org; Thu, 22 Sep 2016 06:40:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bn1QP-0006zE-36 for emacs-devel@gnu.org; Thu, 22 Sep 2016 06:40:18 -0400 Original-Received: from out2-smtp.messagingengine.com ([66.111.4.26]:57127) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bn1QI-0006pS-FY; Thu, 22 Sep 2016 06:40:12 -0400 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id ECF53206F5; Thu, 22 Sep 2016 06:39:59 -0400 (EDT) Original-Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Thu, 22 Sep 2016 06:39:59 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=8MDzb R3mSgUY9DPuwb75r3RIBy4=; b=atPTxVnvG38Zf+cSJyP7Okt7H4B/gYZZjoRT9 KC5Wb4MtLwXymzF1YqCA8vg2Swau13jmlbyjekZg3CdGk7imCQ0DO73tGTSEUsYU tup7fBSM1gGcnP7iEedOavAhEM7FJxIVHCknv0FFk1teM27ErY8uRUN4GIRPjLz1 RXtxZk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=8MDzbR3mSgUY9DPuwb75r3RIBy4=; b=NN2Dr YWtYUOvp9ffU+Sxc42q11lTrl/vz2PAWHrGxkIU/7CLiuSM3iP6e+qYHTFYUoGWy rOcmAD1YvXCTjNkFtnIclkCZKpp0I+GEFmZZBF8rrNdSaV0cBT8qRkvGCQHoGi6g MVipieT4jBgw6WXF0/zps5Rv9dAf+7UOqMSnaE= X-Sasl-enc: L5kDnMb1YQu8XzFIqKlC8B5S+YeJ6Z/HCbLgbWrJtnIL 1474540799 Original-Received: from thinkpad (79.138.129.132.mobile.tre.se [79.138.129.132]) by mail.messagingengine.com (Postfix) with ESMTPA id EDB4DCCE9E; Thu, 22 Sep 2016 06:39:58 -0400 (EDT) In-Reply-To: <83fuotfcw4.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 21 Sep 2016 19:14:51 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 66.111.4.26 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:207686 Archived-At: Eli Zaretskii 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.