From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Andreas Politz Newsgroups: gmane.emacs.devel Subject: Re: Overlays as an AA-tree Date: Mon, 20 Feb 2017 00:44:00 +0100 Message-ID: <87zihhkapr.fsf@hochschule-trier.de> References: <87d1jylv43.fsf@fastmail.com> <87fujv64mn.fsf@hochschule-trier.de> <87fujvpkzc.fsf@fastmail.com> <87vasr5tqd.fsf@hochschule-trier.de> <87d1ex4kon.fsf@hochschule-trier.de> <87d1evod6x.fsf@fastmail.com> <877f53ftab.fsf@hochschule-trier.de> <878tpiqiuc.fsf@hochschule-trier.de> <87shnppspb.fsf@hochschule-trier.de> <87o9yc9v30.fsf@hochschule-trier.de> <87a89vaes3.fsf@hochschule-trier.de> <87efz7n0g5.fsf@fastmail.com> <877f4uah6i.fsf@hochschule-trier.de> <83k28u1uyz.fsf@gnu.org> <871suxs9ad.fsf@hochschule-trier.de> <837f4pxpdc.fsf@gnu.org> <877f4lls9e.fsf@hochschule-trier.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1487547876 8355 195.159.176.226 (19 Feb 2017 23:44:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 19 Feb 2017 23:44:36 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 20 00:44:31 2017 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 1cfb9a-0001VS-OH for ged-emacs-devel@m.gmane.org; Mon, 20 Feb 2017 00:44:30 +0100 Original-Received: from localhost ([::1]:35422 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cfb9e-0005Km-Bw for ged-emacs-devel@m.gmane.org; Sun, 19 Feb 2017 18:44:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36447) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cfb9Y-0005KV-B1 for emacs-devel@gnu.org; Sun, 19 Feb 2017 18:44:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cfb9V-00075a-91 for emacs-devel@gnu.org; Sun, 19 Feb 2017 18:44:28 -0500 Original-Received: from gateway-a.fh-trier.de ([143.93.54.181]:58457) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cfb9U-00074V-U8 for emacs-devel@gnu.org; Sun, 19 Feb 2017 18:44:25 -0500 X-Virus-Scanned: by Amavisd-new + McAfee uvscan + ClamAV [Rechenzentrum Hochschule Trier (RZ/HT)] Original-Received: from localhost (ip5f5bdee7.dynamic.kabel-deutschland.de [95.91.222.231]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: politza) by gateway-a.fh-trier.de (Postfix) with ESMTPSA id 4605A179ADDC; Mon, 20 Feb 2017 00:44:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=hochschule-trier.de; s=default; t=1487547849; bh=FNSTc4EfMzSFvgLx5XIFuEJZcaY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:Message-ID: MIME-Version:Content-Type; b=JvhB578/len3DK1kW9wLRHqaT8nHq7qyo3a1J2r0//JDWf/lnFn4w+u1KtaGVyk8G mnhtlvVAfSLEsTUbpKbtgREY+ze7yTFDPMV8kse0LgFbT0N0Col5qKy6ry7MP5aspI PXLRQA6kAax+ar8sXESN5zrwQsDlJkwUej052gok= In-Reply-To: (Stefan Monnier's message of "Sun, 19 Feb 2017 18:10:29 -0500") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x [fuzzy] X-Received-From: 143.93.54.181 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:212482 Archived-At: Stefan Monnier writes: >> Here is one such case were the tree is forced to search through all >> overlays in order to find the next change: > >> |--------------------------| >> |-------------------| >> |-------------| >> B ^ E >> P > >> We are looking for the next change after P, which is E. But E is the >> end of some overlay, and the tree knows nothing about the order of >> these, so it needs to consider all overlays. > > Maybe I don't understand your example, but AFAICT it doesn't need to > consider all overlays: only those that cover P. In this case all of them do. I painted N=3 overlays only. > Even if that results in thousands of overlays in the buffer, any > particular location in the buffer shouldn't have a "folding nesting" so > terribly high that it is covered by hundreds of overlays. Yes, that's a good point. > The complexity of overlays-in and overlays-at is necessarily of O(N) where > N is the number of overlays covering the area. Even O(N log M) (where > M is the total number of overlays) should be fine. Yes, but next-overlay-change (which is a function re-display heavily depends on) does not need all overlays at some position, but just the least of the next end or begin of them. It is not *necessary* to consider all overlays covering some position, its simply the best way of doing it with the current implementations. So, I guess I'm seeing to black then. -ap