From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Newsgroups: gmane.emacs.bugs Subject: bug#25592: Feature request: sorting overlays Date: Sun, 5 Feb 2017 11:21:04 -0500 Message-ID: <21abc5a1-0777-cd33-ff26-2cd0853e9161@live.com> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2VSvoVAEKVCdNQhuKbD5Tr0jUiHPdaR8k" X-Trace: blaine.gmane.org 1486311734 24729 195.159.176.226 (5 Feb 2017 16:22:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 5 Feb 2017 16:22:14 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 Cc: 25592@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Feb 05 17:22: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 1caPZp-0006Iv-NO for geb-bug-gnu-emacs@m.gmane.org; Sun, 05 Feb 2017 17:22:09 +0100 Original-Received: from localhost ([::1]:43716 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1caPZv-0006yK-Dj for geb-bug-gnu-emacs@m.gmane.org; Sun, 05 Feb 2017 11:22:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32780) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1caPZl-0006wO-Ig for bug-gnu-emacs@gnu.org; Sun, 05 Feb 2017 11:22:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1caPZi-0002vL-CJ for bug-gnu-emacs@gnu.org; Sun, 05 Feb 2017 11:22:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58624) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1caPZi-0002vH-99 for bug-gnu-emacs@gnu.org; Sun, 05 Feb 2017 11:22:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1caPZi-0005dV-1X for bug-gnu-emacs@gnu.org; Sun, 05 Feb 2017 11:22:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Feb 2017 16:22:01 +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.148631168221614 (code B ref 25592); Sun, 05 Feb 2017 16:22:01 +0000 Original-Received: (at 25592) by debbugs.gnu.org; 5 Feb 2017 16:21:22 +0000 Original-Received: from localhost ([127.0.0.1]:56823 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1caPZ4-0005cY-AT for submit@debbugs.gnu.org; Sun, 05 Feb 2017 11:21:22 -0500 Original-Received: from mout.kundenserver.de ([217.72.192.75]:50241) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1caPZ1-0005cK-NC for 25592@debbugs.gnu.org; Sun, 05 Feb 2017 11:21:20 -0500 Original-Received: from [192.168.1.106] ([67.186.135.89]) by mrelayeu.kundenserver.de (mreue104 [212.227.15.184]) with ESMTPSA (Nemesis) id 0MeSpb-1cnobn279b-00QCoW; Sun, 05 Feb 2017 17:21:12 +0100 In-Reply-To: <83r33etluz.fsf@gnu.org> X-Provags-ID: V03:K0:1xOlHnp58NVsq9aYc43SPMj7rHV5BJT0oXvhGCWqIc0SyM6Ft3h vHHZdmCXNWbquSJXBhlfC0tqVXPAxSMn46dzz9Wpv71SbA+c+zeqzLJ29resmJB/2xIzmOR CRm8x85oqH5FtqNFMW+7SDnj+MrcYqBl5XAfiN6qVEKL2p2o5neYRPJev8zUaTFNpYKC8Lj aHesO8/gl+2b/cwH0jcKw== X-UI-Out-Filterresults: notjunk:1;V01:K0:vLsTV3g8P9c=:7VlvvFVdRUyrTxshq62mpq MNfDLCfD3S080FIrA899mvJdJHkVpxKq7DSfjsEDBJiXHhp58dTX3yqV5IbNRTV4GCC2bJmGf BW9ReaaPzDTHm311p5lRHANBKD6lVo2JaUvq1TxppKqFx+l17GJkCF9+BMiGH+/lUN42Cnb63 DPNcic/dgzUmehzrY3KVUlca3MYrMRC+u5u6wZdGdlSvhSmt4chog7YxmS9O/ballCW1Su+kk GCFxry5PZOuBmm7EFgzPy5qKU9OyBQcjrEZKsX/LOu4VJrYufZtUGkOQrQrSdFg9W1Pglxsgg hU9ypdXOTaDr5hlaP4naIPlKA+V9k4AfEv9ouNuyBm3RLBq/zG1rVY0kwdImUtsNgB/DsKMfY znle84A17ccCM3kiCCMK5Oo2y0C2V8GcGq2uXJ7wV29mrNtvVYpnBhjaTK1ZWxCv4a6QTwiT8 MVvBfKwDWiYvWMdg2GovAU4lOwinKMOPW5r4/348YWpkP/pRh546G2H+BP3miuFS53i2h8GGK e09TtYu7w1DyqYHA8T/NvCf24wg3sChdINi4VfTD+moCIiM59RsUhpYkfrLp/z5alf7ai0hXe WWrVrXR0EVPI8qcjqtCeVtI1EfU+n4Az6vTSSS2iOL9V0rhnJaFJQnFzxUrb5LcVClVFdGe2l CPTnbXDc2VbHO9d9OXA7Kb5lbMQ8zhqawiCLBSUG5Ar9ugOkyEfcfy4HnlM+lwzM/SfE= 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:128986 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2VSvoVAEKVCdNQhuKbD5Tr0jUiHPdaR8k Content-Type: multipart/mixed; boundary="MwFqiPdsEx02Gqx62LXQnbx9RUVnQ8KOC"; protected-headers="v1" From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= To: Eli Zaretskii Cc: 25592@debbugs.gnu.org Message-ID: <21abc5a1-0777-cd33-ff26-2cd0853e9161@live.com> Subject: Re: bug#25592: Feature request: sorting overlays 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> In-Reply-To: <83r33etluz.fsf@gnu.org> --MwFqiPdsEx02Gqx62LXQnbx9RUVnQ8KOC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2017-02-04 03:13, Eli Zaretskii wrote: >> Cc: 25592@debbugs.gnu.org From: Cl=C3=A9ment Pit--Claudel >> Date: Fri, 3 Feb 2017 16:51:24 -0500 >>=20 >>>> No: I'm iterating over all overlays, and applying them one by >>>> one. >>>=20 >>> Why not do it as I suggest? Then your problems with sorting will >>> be solved as a nice side-effect. >>=20 >> 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). >=20 > Why would you need to keep track of overlays, if you always process=20 > each one just once? To avoid applying the same overlay twice. But I think I understand your s= uggestion better now, and you meant that I would apply each overlay's pro= perties not to the entire overlay's range (overlay-start .. overlay-end),= but instead just to the current range (as determined by next-overlay-cha= nge). Correct? =20 > As for costs, next-overlay-change (or one of its variants) is used > by the display engine in its inner loops (see=20 > compute_display_string_pos), so it should be fast enough for your=20 > needs, I think. I see, thanks. I'll consider this option, then! >> 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. >=20 > But the "simpler" solution has a problem, whereby the order of the=20 > overlays might depend on buffer position for which you evaluate the=20 > order, because overlays could begin at the same position, but end at=20 > 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 understa= nd the problem. Here's my current algorithm: (defun esh--filter-plist (plist props) "Remove PROPS from PLIST." (let ((filtered nil)) (esh--doplist (prop val plist) (unless (memq prop props) (push prop filtered) (push val filtered))) (nreverse filtered))) (defun esh--number-or-0 (x) "Return X if X is a number, 0 otherwise." (if (numberp x) x 0)) (defun esh--augment-overlay (ov) "Return a list of three values: the priorities of overlay OV, and OV." (let ((pr (overlay-get ov 'priority))) (if (consp pr) (list (esh--number-or-0 (car pr)) (esh--number-or-0 (cdr pr)) ov)= (list (esh--number-or-0 pr) 0 ov)))) (defun esh--augmented-overlay-< (ov1 ov2) "Compare two lists OV1 OV2 produced by `esh--augment-overlay'." (or (< (car ov1) (car ov2)) (and (=3D (car ov1) (car ov2)) (< (cadr ov1) (cadr ov2))))) (defun esh--buffer-overlays (buf) "Collects overlays of BUF, in order of increasing priority." (let* ((ovs (with-current-buffer buf (overlays-in (point-min) (point-ma= x)))) (augmented (mapcar #'esh--augment-overlay ovs)) (sorted (sort augmented #'esh--augmented-overlay-<))) (mapcar #'cl-caddr sorted))) (defconst esh--overlay-specific-props '(after-string before-string evaporate isearch-open-invisible isearch-open-invisible-temporary priority window) "Properties that only apply to overlays.") (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-pro= ps)))) (when face (font-lock-prepend-text-property start end 'face face)) (add-text-properties start end props))))) I can trim the code to remove bits that are not directly relevant, if you= want. >>>>> How did you implement in Lisp the "last resort" of >>>>> comparison, which compares addresses of the C structs? >>>>=20 >>>> I didn't :) >>>=20 >>> So it isn't really a solution ;-) >>=20 >> It's not a full reimplementation, but it's enough of a solution for >> me :) The docs say =E2=80=9CIf SORTED is non-=E2=80=98nil=E2=80=99, th= e list is in >> decreasing order of priority=E2=80=9D, and that's what my implementati= on >> does. >=20 > Then there will be use cases where your solution will give a wrong=20 > value to the text property that replaces the overlays. Snap. Do you have a concrete example? I imagine this would happen if tw= o overlays are added to the same range of text, with no explicit priority= ? Thanks for your comments! Cl=C3=A9ment. --MwFqiPdsEx02Gqx62LXQnbx9RUVnQ8KOC-- --2VSvoVAEKVCdNQhuKbD5Tr0jUiHPdaR8k Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYl1D1AAoJEPqg+cTm90wjnhEQAJzyuZNVMo8ySoOrXI7OTXno MyzqiOTP6KVYJHzeJG5tM5H2BpsdWfYfsRkScUfptUWAU97p2tv2mGnRT0T40c6f PQgbmOaJ7Fd3m+B/G5DUGY4bNjE6FrcG+3LcpqnP1dkp1KpnP8pBPT+5dui7iwge NRSR4O4jSg1EqKccFLn8ykvDAhT3LJ10eHrPJKGQh/VF44wPkoHeFqS9Nir6bbjN xB8Fyx2xn4KIpTCnPi7BI/SvId+Nq6g/D1A2FODoIPfT5bchVBDghwVBqTEUVd67 sO3LHoziLCLJtJizXNsuSlLJQUAv72edktsDtmOtnr6JKT2MLyrgdpA7EZJh9O/W hsGHrh67n5A3bgW9TgUV93GgsJTI/jWYmTuLvWRWR/Ewy32g2y3E5sl6NtOJekM3 rCFj5S2M6ePrdwbtxJovODhqGDRw803a+2V0ZnJY4hpoDmWOpwwyxfKeOzs0wv2t ztivTpimNuFvWIbtFX4HG19YG91wQqNhKfhL3Epk9UHNccBOF7bd7a/hDCQNfWuE QJopWIysNubE6A53d2oY2ZIvNBwxJAZ2vSJWCH40C+rp1BtAXL5yw5UyelLC0xUW vfDVwXgEjEDqd5vbikIZ1B3rqEXnN5fVQ66Q7h0WCqdHUcOmK7OFTLPaDNyT8V6g jzsp7Wf8D9EnVeIPT+uT =yMkS -----END PGP SIGNATURE----- --2VSvoVAEKVCdNQhuKbD5Tr0jUiHPdaR8k--