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: Sun, 05 Feb 2017 20:28:53 +0200 Message-ID: <83wpd47aqi.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> <83r33etluz.fsf@gnu.org> <21abc5a1-0777-cd33-ff26-2cd0853e9161@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 1486319416 20771 195.159.176.226 (5 Feb 2017 18:30:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 5 Feb 2017 18:30:16 +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 Sun Feb 05 19:30: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 1caRZh-00055e-Fh for geb-bug-gnu-emacs@m.gmane.org; Sun, 05 Feb 2017 19:30:10 +0100 Original-Received: from localhost ([::1]:44098 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1caRZl-0007zI-9t for geb-bug-gnu-emacs@m.gmane.org; Sun, 05 Feb 2017 13:30:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53136) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1caRZf-0007xv-EF for bug-gnu-emacs@gnu.org; Sun, 05 Feb 2017 13:30:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1caRZa-0003Qg-TM for bug-gnu-emacs@gnu.org; Sun, 05 Feb 2017 13:30:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58655) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1caRZa-0003QT-Pf for bug-gnu-emacs@gnu.org; Sun, 05 Feb 2017 13:30:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1caRZa-00005I-Iz for bug-gnu-emacs@gnu.org; Sun, 05 Feb 2017 13:30:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Feb 2017 18:30: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.148631935432706 (code B ref 25592); Sun, 05 Feb 2017 18:30:02 +0000 Original-Received: (at 25592) by debbugs.gnu.org; 5 Feb 2017 18:29:14 +0000 Original-Received: from localhost ([127.0.0.1]:56854 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1caRYo-0008VS-FZ for submit@debbugs.gnu.org; Sun, 05 Feb 2017 13:29:14 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:33846) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1caRYm-0008VF-Je for 25592@debbugs.gnu.org; Sun, 05 Feb 2017 13:29:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1caRYc-000382-SN for 25592@debbugs.gnu.org; Sun, 05 Feb 2017 13:29:07 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37793) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1caRYc-00037x-Pp; Sun, 05 Feb 2017 13:29:02 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3753 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1caRYb-0007r3-JA; Sun, 05 Feb 2017 13:29:02 -0500 In-reply-to: <21abc5a1-0777-cd33-ff26-2cd0853e9161@live.com> (message from =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel on Sun, 5 Feb 2017 11:21:04 -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:128990 Archived-At: > Cc: 25592@debbugs.gnu.org > From: Clément Pit--Claudel > Date: Sun, 5 Feb 2017 11:21:04 -0500 > > > Why would you need to keep track of overlays, if you always process > > each one just once? > > To avoid applying the same overlay twice. But I think I understand your suggestion better now, and you meant that I would apply each overlay's properties not to the entire overlay's range (overlay-start .. overlay-end), but instead just to the current range (as determined by next-overlay-change). Correct? Yes, of course. That's how the display engine handles overlays. > > 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? > > I think I'm probably the one missing something :) I'm not sure I understand the problem. Here's my current algorithm: > [...] > (defun esh--commit-overlays (buf) > "Copy overlays of BUF into current buffer's text properties." > (let ((pt-min-diff (- (with-current-buffer buf (point-min)) (point-min)))) > (dolist (ov (esh--buffer-overlays buf)) > (let* ((start (max (point-min) (- (overlay-start ov) pt-min-diff))) > (end (min (point-max) (- (overlay-end ov) pt-min-diff))) > (ov-props (overlay-properties ov)) > (cat-props (let ((symbol (plist-get ov-props 'category))) > (and symbol (symbol-plist symbol)))) > (face (let ((mem (plist-member ov-props 'face))) > (if mem (cadr mem) (plist-get cat-props 'face)))) > (props (esh--filter-plist (append cat-props ov-props) > (cons 'face esh--overlay-specific-props)))) > (when face > (font-lock-prepend-text-property start end 'face face)) > (add-text-properties start end props))))) What will happen if you have 2 overlays like this: +------------- OV2 -------+ xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx +------- OV1 ---------+ and OV2 has a higher priority than OV1? > >>>>> 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. > > Snap. Do you have a concrete example? I imagine this would happen if two overlays are added to the same range of text, with no explicit priority? Or with explicitly equal priority.