From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#25592: Feature request: sorting overlays Date: Sat, 04 Feb 2017 10:13:08 +0200 Message-ID: <83r33etluz.fsf@gnu.org> References: <837f5avzdm.fsf@gnu.org> <75813a2b-ba63-e356-d766-cd9ae77b28e2@live.com> <83mve4uxwr.fsf@gnu.org> <83tw8bt1mh.fsf@gnu.org> <1d90ade3-b0a4-f07a-d424-b052a68fd4a7@live.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1486196054 25803 195.159.176.226 (4 Feb 2017 08:14:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 4 Feb 2017 08:14:14 +0000 (UTC) Cc: 25592@debbugs.gnu.org To: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 04 09:14:10 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1cZvU2-0006TZ-7W for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Feb 2017 09:14:10 +0100 Original-Received: from localhost ([::1]:38346 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZvU6-0002Ov-0v for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Feb 2017 03:14:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51840) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZvTz-0002OU-H3 for bug-gnu-emacs@gnu.org; Sat, 04 Feb 2017 03:14:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cZvTv-0006IG-I2 for bug-gnu-emacs@gnu.org; Sat, 04 Feb 2017 03:14:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57282) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cZvTv-0006I4-FT for bug-gnu-emacs@gnu.org; Sat, 04 Feb 2017 03:14:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cZvTu-0003v8-3N for bug-gnu-emacs@gnu.org; Sat, 04 Feb 2017 03:14:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Feb 2017 08:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25592 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25592-submit@debbugs.gnu.org id=B25592.148619601015026 (code B ref 25592); Sat, 04 Feb 2017 08:14:02 +0000 Original-Received: (at 25592) by debbugs.gnu.org; 4 Feb 2017 08:13:30 +0000 Original-Received: from localhost ([127.0.0.1]:55481 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cZvTO-0003uH-3J for submit@debbugs.gnu.org; Sat, 04 Feb 2017 03:13:30 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:60488) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cZvTN-0003u6-14 for 25592@debbugs.gnu.org; Sat, 04 Feb 2017 03:13:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cZvTD-0005ox-Nf for 25592@debbugs.gnu.org; Sat, 04 Feb 2017 03:13:23 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46071) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZvTD-0005ol-KA; Sat, 04 Feb 2017 03:13:19 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4584 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cZvTC-0007rh-0D; Sat, 04 Feb 2017 03:13:18 -0500 In-reply-to: <1d90ade3-b0a4-f07a-d424-b052a68fd4a7@live.com> (message from =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel on Fri, 3 Feb 2017 16:51:24 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:128934 Archived-At: > Cc: 25592@debbugs.gnu.org > From: Clément Pit--Claudel > Date: Fri, 3 Feb 2017 16:51:24 -0500 > > >> No: I'm iterating over all overlays, and applying them one by one. > > > > Why not do it as I suggest? Then your problems with sorting will be > > solved as a nice side-effect. > > I'm worried about the cost and the additional implementation complexity. My current algorithm is very simple: iterate over overlays, applying their properties to the ranges they cover. In contrast, scanning over overlays introduces additional complexity (I need to keep track of which overlays I have already applied and move around the buffer), and additional costs (next-overlay-change seems to do quite a bit of work). Why would you need to keep track of overlays, if you always process each one just once? As for costs, next-overlay-change (or one of its variants) is used by the display engine in its inner loops (see compute_display_string_pos), so it should be fast enough for your needs, I think. > None of this is a show stopper (in fact, I don't even know for sure that the slowdown would be significant, and I do know that I don't expect to have that many overlays anyway :), but it'd be nice to be able to use the "simpler" solution. But the "simpler" solution has a problem, whereby the order of the overlays might depend on buffer position for which you evaluate the order, because overlays could begin at the same position, but end at different ones, or vice versa. IOW, the overlaps between portions of the buffer text "covered" by different overlays could be partial. How do you handle this situation in your algorithm? The correct solution would require having different values of the corresponding text property for different locations, according to the highest-priority overlay at each location. Am I missing something? > >>> How did you implement in Lisp the "last resort" of comparison, which > >>> compares addresses of the C structs? > >> > >> I didn't :) > > > > So it isn't really a solution ;-) > > It's not a full reimplementation, but it's enough of a solution for me :) The docs say “If SORTED is non-‘nil’, the list is in decreasing order of priority”, and that's what my implementation does. Then there will be use cases where your solution will give a wrong value to the text property that replaces the overlays.