From unknown Sat Aug 09 15:54:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25751: Query replace lazy highlighting Resent-From: Antoine Levitt Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Feb 2017 13:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 25751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 25751@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.148725105829389 (code B ref -1); Thu, 16 Feb 2017 13:18:01 +0000 Received: (at submit) by debbugs.gnu.org; 16 Feb 2017 13:17:38 +0000 Received: from localhost ([127.0.0.1]:41776 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ceLwI-0007dx-4K for submit@debbugs.gnu.org; Thu, 16 Feb 2017 08:17:38 -0500 Received: from eggs.gnu.org ([208.118.235.92]:39170) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ceLwH-0007dk-3U for submit@debbugs.gnu.org; Thu, 16 Feb 2017 08:17:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ceLw5-00026s-Up for submit@debbugs.gnu.org; Thu, 16 Feb 2017 08:17:31 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:51701) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ceLw5-00026n-RV for submit@debbugs.gnu.org; Thu, 16 Feb 2017 08:17:25 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ceLw4-0004mb-HU for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2017 08:17:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ceLw1-00025Z-CI for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2017 08:17:24 -0500 Received: from mail-wr0-x230.google.com ([2a00:1450:400c:c0c::230]:33156) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ceLw1-00025L-5u for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2017 08:17:21 -0500 Received: by mail-wr0-x230.google.com with SMTP id i10so11474812wrb.0 for ; Thu, 16 Feb 2017 05:17:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:from:to:subject:date:message-id:mime-version; bh=x+xgEs3gBqXLBG9NFJtt3FUJ/UPdcxwl8Hi4N9lCUHg=; b=RMa2Fr2HLwydggb68pzG+8cRYY4giaehQ2gNOJhsGfIC2/CLFIzIug1W7D4g65x8NM xdJq/XN+RFM893bxBHiSECXLeMOpeiA2qrgPtYI81AJO33RWaie7lY13iT//YE0iQDL8 lKN7DCqNR49qyrgm1/jozSCVJi8gPcrSyim+8AwhM31Xx/mQw8ph6deZx1TeXkbK1A9V cG1Oi5nsCaf9z9/BuGOzSophv2TLKu0sunrPPg2NPa9saPxLdoNpTnu8OHyGuMdCeBQ5 jRzLcfFftC7ItqD7xHd9W2bTG9wmDs6DlgYJWqh/1Qw6Bq+HmTctSLCEAscS3J16B+2j zsFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:from:to:subject:date:message-id :mime-version; bh=x+xgEs3gBqXLBG9NFJtt3FUJ/UPdcxwl8Hi4N9lCUHg=; b=OEJgHFYHveb9ysOkbATzrbjudYupfIKzY/3ocVuoQ/omHxXZfGGn8a/I4gALDX/HiS tELVivGACwuWCeWZgn0rPB7ke41brpfdzQQIvNMzG6wrFoaVQrVU7TcSuzNG67S2Y6IP kJ2BspAPqo9gRCFlUYPSMwI9bff5Noiv76PhStjUQmAJNVYc/SOQ9uyqouIiXZsVd3gA ZuG/7t3jGJsAJQsgibRyqDNx52tNvnyjTch5F6+nk5YIRXGRRxeH8DreZYp6oVVABnOY 5xGQbyQd95DnZRRxhOAWKhckU9lpCmGPbHpsnjiGypvzKLwHlqtELTJR9LZiReHA8tdk FBew== X-Gm-Message-State: AMke39nwVOTHk5e1mvpzAeEeOzndhxMTpbxX1+rlqwhXNfGlAmcpKYOAgZ2rvoaBjv5K5w== X-Received: by 10.223.133.220 with SMTP id 28mr2440543wru.97.1487251039770; Thu, 16 Feb 2017 05:17:19 -0800 (PST) Received: from lambda (fw.enpc.fr. [194.57.247.3]) by smtp.gmail.com with ESMTPSA id 45sm8913965wrx.60.2017.02.16.05.17.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 05:17:18 -0800 (PST) User-agent: mu4e 0.9.17; emacs 26.0.50.1 From: Antoine Levitt Date: Thu, 16 Feb 2017 14:18:31 +0100 Message-ID: <87mvdmxoig.fsf@lambda> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) (apologies if this has been posted before, but I can't find any references) When query-replacing and confirming, matches get unhighlighted, and then highlighted again, which is very distracting. E.g. open a file, M-% a -> a, y, other matches of a get unhighlighted then highlighted again. (setq lazy-highlight-initial-delay 0) (shouldn't it be default by the way, at least on graphical displays?) reduces the problem but does not eliminate it (it produces small flickers). There's lazy-highlight-cleanup, but that disables cleanup completely, which I don't want. Can't this be eliminated? Best, Antoine From unknown Sat Aug 09 15:54:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25751: Query replace lazy highlighting Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Feb 2017 21:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Antoine Levitt Cc: 25751@debbugs.gnu.org Received: via spool by 25751-submit@debbugs.gnu.org id=B25751.14872791527044 (code B ref 25751); Thu, 16 Feb 2017 21:06:02 +0000 Received: (at 25751) by debbugs.gnu.org; 16 Feb 2017 21:05:52 +0000 Received: from localhost ([127.0.0.1]:42673 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ceTFP-0001pY-Ok for submit@debbugs.gnu.org; Thu, 16 Feb 2017 16:05:51 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:40115 helo=homiemail-a39.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ceTFM-0001pI-N8 for 25751@debbugs.gnu.org; Thu, 16 Feb 2017 16:05:48 -0500 Received: from homiemail-a39.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a39.g.dreamhost.com (Postfix) with ESMTP id 4C14F150074; Thu, 16 Feb 2017 13:05:48 -0800 (PST) Received: from localhost.linkov.net (m83-191-240-183.cust.tele2.ee [83.191.240.183]) (Authenticated sender: jurta@jurta.org) by homiemail-a39.g.dreamhost.com (Postfix) with ESMTPA id 739EE150069; Thu, 16 Feb 2017 13:05:47 -0800 (PST) From: Juri Linkov Organization: LINKOV.NET References: <87mvdmxoig.fsf@lambda> Date: Thu, 16 Feb 2017 23:01:28 +0200 In-Reply-To: <87mvdmxoig.fsf@lambda> (Antoine Levitt's message of "Thu, 16 Feb 2017 14:18:31 +0100") Message-ID: <87wpcpx32v.fsf@localhost> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > When query-replacing and confirming, matches get unhighlighted, and the= n > highlighted again, which is very distracting. E.g. open a file, M-% a -= > > a, y, other matches of a get unhighlighted then highlighted again. > > (setq lazy-highlight-initial-delay 0) (shouldn't it be default by the > way, at least on graphical displays?) reduces the problem but does not > eliminate it (it produces small flickers). There's > lazy-highlight-cleanup, but that disables cleanup completely, which I > don't want. > > Can't this be eliminated? The reason why it works this way is because lazy-highlight is not yet optimized to handle changes: it needs to dehighlight the replaced text, and to add highlighting in the new replacing text after every replacement= . I see no simpler solution than to write a new function with a name like =E2=80=98isearch-lazy-highlight-update-in-region=E2=80=99 that given the = region boundaries of the last replacement will rehighlight matches in that region. From unknown Sat Aug 09 15:54:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25751: Query replace lazy highlighting Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Feb 2017 22:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Antoine Levitt Cc: 25751@debbugs.gnu.org Received: via spool by 25751-submit@debbugs.gnu.org id=B25751.148728523016213 (code B ref 25751); Thu, 16 Feb 2017 22:48:02 +0000 Received: (at 25751) by debbugs.gnu.org; 16 Feb 2017 22:47:10 +0000 Received: from localhost ([127.0.0.1]:42762 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ceUpQ-0004DP-Cd for submit@debbugs.gnu.org; Thu, 16 Feb 2017 17:47:08 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:34130 helo=homiemail-a39.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ceUpP-0004DI-76 for 25751@debbugs.gnu.org; Thu, 16 Feb 2017 17:47:07 -0500 Received: from homiemail-a39.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a39.g.dreamhost.com (Postfix) with ESMTP id 8A4F415006D; Thu, 16 Feb 2017 14:47:04 -0800 (PST) Received: from localhost.linkov.net (m83-191-240-183.cust.tele2.ee [83.191.240.183]) (Authenticated sender: jurta@jurta.org) by homiemail-a39.g.dreamhost.com (Postfix) with ESMTPA id B41E2150069; Thu, 16 Feb 2017 14:47:03 -0800 (PST) From: Juri Linkov Organization: LINKOV.NET References: <87mvdmxoig.fsf@lambda> <87wpcpx32v.fsf@localhost> Date: Fri, 17 Feb 2017 00:45:05 +0200 In-Reply-To: <87wpcpx32v.fsf@localhost> (Juri Linkov's message of "Thu, 16 Feb 2017 23:01:28 +0200") Message-ID: <87vas9sqku.fsf@localhost> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) >> When query-replacing and confirming, matches get unhighlighted, and th= en >> highlighted again, which is very distracting. E.g. open a file, M-% a = -> >> a, y, other matches of a get unhighlighted then highlighted again. >> >> (setq lazy-highlight-initial-delay 0) (shouldn't it be default by the >> way, at least on graphical displays?) reduces the problem but does not >> eliminate it (it produces small flickers). There's >> lazy-highlight-cleanup, but that disables cleanup completely, which I >> don't want. >> >> Can't this be eliminated? > > The reason why it works this way is because lazy-highlight is not yet > optimized to handle changes: it needs to dehighlight the replaced text, > and to add highlighting in the new replacing text after every replaceme= nt. > I see no simpler solution than to write a new function with a name like > =E2=80=98isearch-lazy-highlight-update-in-region=E2=80=99 that given th= e region boundaries > of the last replacement will rehighlight matches in that region. Actually, there are too many special casing to optimize that makes this solution too brittle: for example, replacing a string with shorter text requires highlighting new matches at the window-end minus the length of t= he deleted text, i.e. deletion shifts previously invisible text into the vie= w where matches should be highlighted. But I realized that fortunately there is a better and simpler solution. The problem is not specific to replacement, the same flicker exists in is= earch, e.g. while scrolling by one line where all overlays are deleted, and created again in the same places. To void flickering the best solution i= s to delete old overlays AFTER adding new ones, not BEFORE as it is now - this works pleasingly well: diff --git a/lisp/isearch.el b/lisp/isearch.el index 5262435..9cb5399 100644 --- a/lisp/isearch.el +++ b/lisp/isearch.el @@ -3101,6 +3101,7 @@ (defun isearch-dehighlight () ;; only if `isearch-string' is an invalid regexp. =20 (defvar isearch-lazy-highlight-overlays nil) +(defvar isearch-lazy-highlight-overlays-old nil) (defvar isearch-lazy-highlight-wrapped nil) (defvar isearch-lazy-highlight-start-limit nil) (defvar isearch-lazy-highlight-end-limit nil) @@ -3173,7 +3174,7 @@ (defun isearch-lazy-highlight-new-loop (&optional b= eg end) (not (equal isearch-error isearch-lazy-highlight-error)))) ;; something important did indeed change - (lazy-highlight-cleanup t) ;kill old loop & remove overlays + (setq isearch-lazy-highlight-overlays-old isearch-lazy-highlight-ove= rlays) (setq isearch-lazy-highlight-error isearch-error) ;; It used to check for `(not isearch-error)' here, but actually ;; lazy-highlighting might find matches to highlight even when @@ -3315,6 +3316,11 @@ (defun isearch-lazy-highlight-update () (setq isearch-lazy-highlight-start (window-group-end)) (goto-char (min (or isearch-lazy-highlight-end-limit (point-max)) (window-group-end)))))))) + (when nomore + ;; Remove old overlays + (let ((isearch-lazy-highlight-overlays isearch-lazy-highli= ght-overlays-old) + (isearch-lazy-highlight-timer nil)) + (lazy-highlight-cleanup t))) (unless nomore (setq isearch-lazy-highlight-timer (run-at-time lazy-highlight-interval nil From unknown Sat Aug 09 15:54:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25751: Query replace lazy highlighting Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 Feb 2017 06:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 25751@debbugs.gnu.org, antoine.levitt@gmail.com Reply-To: Eli Zaretskii Received: via spool by 25751-submit@debbugs.gnu.org id=B25751.148731343226817 (code B ref 25751); Fri, 17 Feb 2017 06:38:01 +0000 Received: (at 25751) by debbugs.gnu.org; 17 Feb 2017 06:37:12 +0000 Received: from localhost ([127.0.0.1]:42975 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cecAK-0006yS-CV for submit@debbugs.gnu.org; Fri, 17 Feb 2017 01:37:12 -0500 Received: from eggs.gnu.org ([208.118.235.92]:54795) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cecAI-0006yF-Qf for 25751@debbugs.gnu.org; Fri, 17 Feb 2017 01:37:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cecA9-00089n-2s for 25751@debbugs.gnu.org; Fri, 17 Feb 2017 01:37:05 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38292) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cecA8-00089d-Vd; Fri, 17 Feb 2017 01:37:01 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3093 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cecA8-0000Hy-4k; Fri, 17 Feb 2017 01:37:00 -0500 Date: Fri, 17 Feb 2017 08:37:26 +0200 Message-Id: <83d1ehxqzd.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87wpcpx32v.fsf@localhost> (message from Juri Linkov on Thu, 16 Feb 2017 23:01:28 +0200) References: <87mvdmxoig.fsf@lambda> <87wpcpx32v.fsf@localhost> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Juri Linkov > Date: Thu, 16 Feb 2017 23:01:28 +0200 > Cc: 25751@debbugs.gnu.org > > > (setq lazy-highlight-initial-delay 0) (shouldn't it be default by the > > way, at least on graphical displays?) reduces the problem but does not > > eliminate it (it produces small flickers). There's > > lazy-highlight-cleanup, but that disables cleanup completely, which I > > don't want. > > > > Can't this be eliminated? > > The reason why it works this way is because lazy-highlight is not yet > optimized to handle changes: it needs to dehighlight the replaced text, > and to add highlighting in the new replacing text after every replacement. > I see no simpler solution than to write a new function with a name like > ‘isearch-lazy-highlight-update-in-region’ that given the region boundaries > of the last replacement will rehighlight matches in that region. I think the problem is not that we remove the highlight and add it anew, the problem is that there's a redisplay cycle in between the removal and the following addition. The fact that setting lazy-highlight-initial-delay alleviates the problem to some extent, but still leaves the flicker tells me that there's a call to sit-for or some such somewhere in the code that processes replacements, and the removal and addition of the highlight are on two different sides of that sit-for call. One possible solution would be to remove the highlight and add it without triggering redisplay, then I'd expect the flicker to go away. Does this make sense? From unknown Sat Aug 09 15:54:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25751: Query replace lazy highlighting Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 Feb 2017 22:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 25751@debbugs.gnu.org, antoine.levitt@gmail.com Received: via spool by 25751-submit@debbugs.gnu.org id=B25751.148737224729650 (code B ref 25751); Fri, 17 Feb 2017 22:58:02 +0000 Received: (at 25751) by debbugs.gnu.org; 17 Feb 2017 22:57:27 +0000 Received: from localhost ([127.0.0.1]:43899 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cerSx-0007i9-H1 for submit@debbugs.gnu.org; Fri, 17 Feb 2017 17:57:27 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:34035 helo=homiemail-a17.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cerSu-0007hz-SS for 25751@debbugs.gnu.org; Fri, 17 Feb 2017 17:57:25 -0500 Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id B8E372B206D; Fri, 17 Feb 2017 14:57:22 -0800 (PST) Received: from localhost.linkov.net (m212-107-59-228.cust.tele2.ee [212.107.59.228]) (Authenticated sender: jurta@jurta.org) by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id B49962B206A; Fri, 17 Feb 2017 14:57:21 -0800 (PST) From: Juri Linkov Organization: LINKOV.NET References: <87mvdmxoig.fsf@lambda> <87wpcpx32v.fsf@localhost> <83d1ehxqzd.fsf@gnu.org> Date: Sat, 18 Feb 2017 00:52:47 +0200 In-Reply-To: <83d1ehxqzd.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 17 Feb 2017 08:37:26 +0200") Message-ID: <87poig2zwg.fsf@localhost> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) >> > (setq lazy-highlight-initial-delay 0) (shouldn't it be default by th= e >> > way, at least on graphical displays?) reduces the problem but does n= ot >> > eliminate it (it produces small flickers). There's >> > lazy-highlight-cleanup, but that disables cleanup completely, which = I >> > don't want. >> > >> > Can't this be eliminated? >> >> The reason why it works this way is because lazy-highlight is not yet >> optimized to handle changes: it needs to dehighlight the replaced text= , >> and to add highlighting in the new replacing text after every replacem= ent. >> I see no simpler solution than to write a new function with a name lik= e >> =E2=80=98isearch-lazy-highlight-update-in-region=E2=80=99 that given t= he region boundaries >> of the last replacement will rehighlight matches in that region. > > I think the problem is not that we remove the highlight and add it > anew, the problem is that there's a redisplay cycle in between the > removal and the following addition. The fact that setting > lazy-highlight-initial-delay alleviates the problem to some extent, > but still leaves the flicker tells me that there's a call to sit-for > or some such somewhere in the code that processes replacements, and > the removal and addition of the highlight are on two different sides > of that sit-for call. One possible solution would be to remove the > highlight and add it without triggering redisplay, then I'd expect the > flicker to go away. > > Does this make sense? This feature is called _lazy_ highlighting where _lazy_ implies that it's intended to highlight matches much later after a lot of redisplay cycles. Currently its steps are the following: 1. Delete old overlays 2. Wait for 0.25 seconds of idle time 3. Highlight first 20 matches 4. Wait 0.0625 seconds 5. Highlight next 20 matches 6. Repeat 4 until all matches are highlighted It makes a big improvement to avoid flicker by moving =E2=80=98Delete old= overlays=E2=80=99 to the end when all new matches are highlighted, essentially extending lazy-highlight with =E2=80=98lazy-cleanup=E2=80=99, i.e. making its clean= up _lazy_ as well. Here is a more tested patch that works especially well for the most frequently used isearch operation of adding characters into the search string - there is no more flicker while typing the search string. diff --git a/lisp/isearch.el b/lisp/isearch.el index 5262435..f8796dd 100644 --- a/lisp/isearch.el +++ b/lisp/isearch.el @@ -3101,6 +3101,7 @@ (defun isearch-dehighlight () ;; only if `isearch-string' is an invalid regexp. =20 (defvar isearch-lazy-highlight-overlays nil) +(defvar isearch-lazy-highlight-overlays-old nil) (defvar isearch-lazy-highlight-wrapped nil) (defvar isearch-lazy-highlight-start-limit nil) (defvar isearch-lazy-highlight-end-limit nil) @@ -3122,13 +3123,22 @@ (define-obsolete-variable-alias 'isearch-lazy-hig= hlight-word (defvar isearch-lazy-highlight-forward nil) (defvar isearch-lazy-highlight-error nil) =20 -(defun lazy-highlight-cleanup (&optional force) +(defun lazy-highlight-cleanup (&optional force lazy) "Stop lazy highlighting and remove extra highlighting from current buf= fer. FORCE non-nil means do it whether or not `lazy-highlight-cleanup' is nil. This function is called when exiting an incremental search if `lazy-highlight-cleanup' is non-nil." (interactive '(t)) - (if (or force lazy-highlight-cleanup) + (if (eq lazy t) + (setq isearch-lazy-highlight-overlays-old + (append isearch-lazy-highlight-overlays-old + isearch-lazy-highlight-overlays)) + (while isearch-lazy-highlight-overlays-old + (delete-overlay (car isearch-lazy-highlight-overlays-old)) + (setq isearch-lazy-highlight-overlays-old + (cdr isearch-lazy-highlight-overlays-old)))) + (when (and (or force lazy-highlight-cleanup) + (not lazy)) (while isearch-lazy-highlight-overlays (delete-overlay (car isearch-lazy-highlight-overlays)) (setq isearch-lazy-highlight-overlays @@ -3173,7 +3183,7 @@ (defun isearch-lazy-highlight-new-loop (&optional b= eg end) (not (equal isearch-error isearch-lazy-highlight-error)))) ;; something important did indeed change - (lazy-highlight-cleanup t) ;kill old loop & remove overlays + (lazy-highlight-cleanup t (not (equal isearch-string ""))) (setq isearch-lazy-highlight-error isearch-error) ;; It used to check for `(not isearch-error)' here, but actually ;; lazy-highlighting might find matches to highlight even when @@ -3315,7 +3325,8 @@ (defun isearch-lazy-highlight-update () (setq isearch-lazy-highlight-start (window-group-end)) (goto-char (min (or isearch-lazy-highlight-end-limit (point-max)) (window-group-end)))))))) - (unless nomore + (if nomore + (lazy-highlight-cleanup t 'delete-old) (setq isearch-lazy-highlight-timer (run-at-time lazy-highlight-interval nil 'isearch-lazy-highlight-update))))))))) From unknown Sat Aug 09 15:54:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25751: Query replace lazy highlighting Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Feb 2017 08:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 25751@debbugs.gnu.org, antoine.levitt@gmail.com Reply-To: Eli Zaretskii Received: via spool by 25751-submit@debbugs.gnu.org id=B25751.14874055717800 (code B ref 25751); Sat, 18 Feb 2017 08:13:02 +0000 Received: (at 25751) by debbugs.gnu.org; 18 Feb 2017 08:12:51 +0000 Received: from localhost ([127.0.0.1]:44114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cf08Q-00021k-Pg for submit@debbugs.gnu.org; Sat, 18 Feb 2017 03:12:50 -0500 Received: from eggs.gnu.org ([208.118.235.92]:45152) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cf08O-00021X-KY for 25751@debbugs.gnu.org; Sat, 18 Feb 2017 03:12:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cf08E-0005MP-V5 for 25751@debbugs.gnu.org; Sat, 18 Feb 2017 03:12:43 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42752) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cf08E-0005ML-SY; Sat, 18 Feb 2017 03:12:38 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4543 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cf08D-0007Up-S1; Sat, 18 Feb 2017 03:12:38 -0500 Date: Sat, 18 Feb 2017 10:13:08 +0200 Message-Id: <83mvdjrk6j.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87poig2zwg.fsf@localhost> (message from Juri Linkov on Sat, 18 Feb 2017 00:52:47 +0200) References: <87mvdmxoig.fsf@lambda> <87wpcpx32v.fsf@localhost> <83d1ehxqzd.fsf@gnu.org> <87poig2zwg.fsf@localhost> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Juri Linkov > Cc: antoine.levitt@gmail.com, 25751@debbugs.gnu.org > Date: Sat, 18 Feb 2017 00:52:47 +0200 > > > I think the problem is not that we remove the highlight and add it > > anew, the problem is that there's a redisplay cycle in between the > > removal and the following addition. The fact that setting > > lazy-highlight-initial-delay alleviates the problem to some extent, > > but still leaves the flicker tells me that there's a call to sit-for > > or some such somewhere in the code that processes replacements, and > > the removal and addition of the highlight are on two different sides > > of that sit-for call. One possible solution would be to remove the > > highlight and add it without triggering redisplay, then I'd expect the > > flicker to go away. > > > > Does this make sense? > > This feature is called _lazy_ highlighting where _lazy_ implies that it's > intended to highlight matches much later after a lot of redisplay cycles. You could still leave the "lazy" part, if you both remove and re-add the overlays after the idle delay. IOW, the important thing is not to have redisplay between removal and addition of the highlight. From unknown Sat Aug 09 15:54:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25751: Query replace lazy highlighting Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Feb 2017 23:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 25751@debbugs.gnu.org, antoine.levitt@gmail.com Received: via spool by 25751-submit@debbugs.gnu.org id=B25751.1487459906602 (code B ref 25751); Sat, 18 Feb 2017 23:19:02 +0000 Received: (at 25751) by debbugs.gnu.org; 18 Feb 2017 23:18:26 +0000 Received: from localhost ([127.0.0.1]:45436 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cfEGo-00009e-7e for submit@debbugs.gnu.org; Sat, 18 Feb 2017 18:18:26 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:40264 helo=homiemail-a17.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cfEGm-00009W-Bd for 25751@debbugs.gnu.org; Sat, 18 Feb 2017 18:18:24 -0500 Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id 7EB442B206D; Sat, 18 Feb 2017 15:18:22 -0800 (PST) Received: from localhost.linkov.net (m212-107-59-228.cust.tele2.ee [212.107.59.228]) (Authenticated sender: jurta@jurta.org) by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id 787772B206A; Sat, 18 Feb 2017 15:18:21 -0800 (PST) From: Juri Linkov Organization: LINKOV.NET References: <87mvdmxoig.fsf@lambda> <87wpcpx32v.fsf@localhost> <83d1ehxqzd.fsf@gnu.org> <87poig2zwg.fsf@localhost> <83mvdjrk6j.fsf@gnu.org> Date: Sun, 19 Feb 2017 01:17:04 +0200 In-Reply-To: <83mvdjrk6j.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 18 Feb 2017 10:13:08 +0200") Message-ID: <87h93rcffj.fsf@localhost> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --=-=-= Content-Type: text/plain >> > I think the problem is not that we remove the highlight and add it >> > anew, the problem is that there's a redisplay cycle in between the >> > removal and the following addition. The fact that setting >> > lazy-highlight-initial-delay alleviates the problem to some extent, >> > but still leaves the flicker tells me that there's a call to sit-for >> > or some such somewhere in the code that processes replacements, and >> > the removal and addition of the highlight are on two different sides >> > of that sit-for call. One possible solution would be to remove the >> > highlight and add it without triggering redisplay, then I'd expect the >> > flicker to go away. >> > >> > Does this make sense? >> >> This feature is called _lazy_ highlighting where _lazy_ implies that it's >> intended to highlight matches much later after a lot of redisplay cycles. > > You could still leave the "lazy" part, if you both remove and re-add > the overlays after the idle delay. IOW, the important thing is not to > have redisplay between removal and addition of the highlight. That's an option too, and here is the tested patch (it sets lazy-highlight-max-at-a-time to nil to avoid redisplay between lazy iterations): --=-=-= Content-Type: text/x-patch Content-Disposition: inline Content-Transfer-Encoding: quoted-printable diff --git a/lisp/isearch.el b/lisp/isearch.el index 5262435..15143ce 100644 --- a/lisp/isearch.el +++ b/lisp/isearch.el @@ -332,7 +332,7 @@ (define-obsolete-variable-alias 'isearch-lazy-highlight= -max-at-a-time 'lazy-highlight-max-at-a-time "22.1") =20 -(defcustom lazy-highlight-max-at-a-time 20 +(defcustom lazy-highlight-max-at-a-time nil "Maximum matches to highlight at a time (for `lazy-highlight'). Larger values may reduce Isearch's responsiveness to user input; smaller values make matches highlight slowly. @@ -3122,13 +3122,13 @@ (define-obsolete-variable-alias 'isearch-lazy-highl= ight-word (defvar isearch-lazy-highlight-forward nil) (defvar isearch-lazy-highlight-error nil) =20 -(defun lazy-highlight-cleanup (&optional force) +(defun lazy-highlight-cleanup (&optional force postpone) "Stop lazy highlighting and remove extra highlighting from current buffe= r. FORCE non-nil means do it whether or not `lazy-highlight-cleanup' is nil. This function is called when exiting an incremental search if `lazy-highlight-cleanup' is non-nil." (interactive '(t)) - (if (or force lazy-highlight-cleanup) + (when (and (or force lazy-highlight-cleanup) (not postpone)) (while isearch-lazy-highlight-overlays (delete-overlay (car isearch-lazy-highlight-overlays)) (setq isearch-lazy-highlight-overlays @@ -3173,7 +3173,7 @@ (defun isearch-lazy-highlight-new-loop (&optional beg= end) (not (equal isearch-error isearch-lazy-highlight-error)))) ;; something important did indeed change - (lazy-highlight-cleanup t) ;kill old loop & remove overlays + (lazy-highlight-cleanup t (not (equal isearch-string ""))) ;stop old t= imer (setq isearch-lazy-highlight-error isearch-error) ;; It used to check for `(not isearch-error)' here, but actually ;; lazy-highlighting might find matches to highlight even when @@ -3204,7 +3204,7 @@ (defun isearch-lazy-highlight-new-loop (&optional beg= end) (unless (equal isearch-string "") (setq isearch-lazy-highlight-timer (run-with-idle-timer lazy-highlight-initial-delay nil - 'isearch-lazy-highlight-update))))) + 'isearch-lazy-highlight-start))))) =20 (defun isearch-lazy-highlight-search () "Search ahead for the next or previous match, for lazy highlighting. @@ -3249,6 +3249,10 @@ (defun isearch-lazy-highlight-search () success) (error nil))) =20 +(defun isearch-lazy-highlight-start () + (lazy-highlight-cleanup t) ;remove old overlays + (isearch-lazy-highlight-update)) + (defun isearch-lazy-highlight-update () "Update highlighting of other matches for current search." (let ((max lazy-highlight-max-at-a-time) --=-=-=-- From unknown Sat Aug 09 15:54:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25751: Query replace lazy highlighting Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Feb 2017 23:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov , Eli Zaretskii Cc: 25751@debbugs.gnu.org, antoine.levitt@gmail.com Received: via spool by 25751-submit@debbugs.gnu.org id=B25751.148746193410210 (code B ref 25751); Sat, 18 Feb 2017 23:53:02 +0000 Received: (at 25751) by debbugs.gnu.org; 18 Feb 2017 23:52:14 +0000 Received: from localhost ([127.0.0.1]:45458 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cfEnW-0002ec-0m for submit@debbugs.gnu.org; Sat, 18 Feb 2017 18:52:14 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:25817) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cfEnT-0002eN-EE for 25751@debbugs.gnu.org; Sat, 18 Feb 2017 18:52:11 -0500 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v1INq4kq001808 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 18 Feb 2017 23:52:05 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v1INq3xP005798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 18 Feb 2017 23:52:04 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v1INq2dj015165; Sat, 18 Feb 2017 23:52:02 GMT MIME-Version: 1.0 Message-ID: <06b2d640-2239-49cb-bb01-0f2f1e1bbf8e@default> Date: Sat, 18 Feb 2017 15:51:59 -0800 (PST) From: Drew Adams References: <87mvdmxoig.fsf@lambda> <87wpcpx32v.fsf@localhost> <83d1ehxqzd.fsf@gnu.org> <87poig2zwg.fsf@localhost> <83mvdjrk6j.fsf@gnu.org> <87h93rcffj.fsf@localhost> In-Reply-To: <87h93rcffj.fsf@localhost> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6753.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-Spam-Score: -5.6 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.6 (-----) > > You could still leave the "lazy" part, if you both remove and re-add > > the overlays after the idle delay. IOW, the important thing is not to > > have redisplay between removal and addition of the highlight. >=20 > That's an option too, and here is the tested patch (it sets > lazy-highlight-max-at-a-time to nil to avoid redisplay between > lazy iterations): How does this relate to what has been discussed so far in bug #21092? From unknown Sat Aug 09 15:54:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25751: Query replace lazy highlighting Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Feb 2017 00:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: Eli Zaretskii , 25751@debbugs.gnu.org, antoine.levitt@gmail.com Received: via spool by 25751-submit@debbugs.gnu.org id=B25751.148755064924675 (code B ref 25751); Mon, 20 Feb 2017 00:31:01 +0000 Received: (at 25751) by debbugs.gnu.org; 20 Feb 2017 00:30:49 +0000 Received: from localhost ([127.0.0.1]:46651 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cfbsO-0006Pv-Pq for submit@debbugs.gnu.org; Sun, 19 Feb 2017 19:30:48 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:59212 helo=homiemail-a17.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cfbsM-0006Pm-37 for 25751@debbugs.gnu.org; Sun, 19 Feb 2017 19:30:46 -0500 Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id 12ECC2B206D; Sun, 19 Feb 2017 16:30:42 -0800 (PST) Received: from localhost.linkov.net (m212-107-59-228.cust.tele2.ee [212.107.59.228]) (Authenticated sender: jurta@jurta.org) by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id C836A2B206A; Sun, 19 Feb 2017 16:30:40 -0800 (PST) From: Juri Linkov Organization: LINKOV.NET References: <87mvdmxoig.fsf@lambda> <87wpcpx32v.fsf@localhost> <83d1ehxqzd.fsf@gnu.org> <87poig2zwg.fsf@localhost> <83mvdjrk6j.fsf@gnu.org> <87h93rcffj.fsf@localhost> <06b2d640-2239-49cb-bb01-0f2f1e1bbf8e@default> Date: Mon, 20 Feb 2017 02:30:06 +0200 In-Reply-To: <06b2d640-2239-49cb-bb01-0f2f1e1bbf8e@default> (Drew Adams's message of "Sat, 18 Feb 2017 15:51:59 -0800 (PST)") Message-ID: <87fuj9k8px.fsf@localhost> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 2.7 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >> > You could still leave the "lazy" part, if you both remove and re-add >> > the overlays after the idle delay. IOW, the important thing is not to >> > have redisplay between removal and addition of the highlight. >> >> That's an option too, and here is the tested patch (it sets >> lazy-highlight-max-at-a-time to nil to avoid redisplay between >> lazy iterations): > > How does this relate to what has been discussed so far in bug #21092? [...] Content analysis details: (2.7 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.7 RCVD_IN_PSBL RBL: Received via a relay in PSBL [69.163.253.7 listed in psbl.surriel.com] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [69.163.253.7 listed in list.dnswl.org] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.7 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >> > You could still leave the "lazy" part, if you both remove and re-add >> > the overlays after the idle delay. IOW, the important thing is not to >> > have redisplay between removal and addition of the highlight. >> >> That's an option too, and here is the tested patch (it sets >> lazy-highlight-max-at-a-time to nil to avoid redisplay between >> lazy iterations): > > How does this relate to what has been discussed so far in bug #21092? [...] Content analysis details: (2.7 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.7 RCVD_IN_PSBL RBL: Received via a relay in PSBL [69.163.253.7 listed in psbl.surriel.com] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [69.163.253.7 listed in list.dnswl.org] >> > You could still leave the "lazy" part, if you both remove and re-add >> > the overlays after the idle delay. IOW, the important thing is not = to >> > have redisplay between removal and addition of the highlight. >> >> That's an option too, and here is the tested patch (it sets >> lazy-highlight-max-at-a-time to nil to avoid redisplay between >> lazy iterations): > > How does this relate to what has been discussed so far in bug #21092? I'm sorry to say that, but setting lazy-highlight-max-at-a-time to nil in the patch here in bug#25751 is a better way to avoid flicker than highlighting all matches in the buffer as it was discussed in bug#21092. I believe that modern hardware can quickly highlight all matches on the screen in one loop without a noticeable delay. But highlighting matches in the whole buffer is another thing. Could you try to see how fast this could be by trying to highlight a single character in a large buffer, e.g. with =E2=80=98M-x highlight-regexp RET a RET RET=E2= =80=99 From unknown Sat Aug 09 15:54:14 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Antoine Levitt Subject: bug#25751: closed (Re: bug#25751: Query replace lazy highlighting) Message-ID: References: <87mvdf164p.fsf@localhost> <87mvdmxoig.fsf@lambda> X-Gnu-PR-Message: they-closed 25751 X-Gnu-PR-Package: emacs Reply-To: 25751@debbugs.gnu.org Date: Tue, 21 Feb 2017 23:24:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1487719442-11674-1" This is a multi-part message in MIME format... ------------=_1487719442-11674-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #25751: Query replace lazy highlighting which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 25751@debbugs.gnu.org. --=20 25751: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D25751 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1487719442-11674-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 25751-done) by debbugs.gnu.org; 21 Feb 2017 23:23:03 +0000 Received: from localhost ([127.0.0.1]:49399 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cgJlv-00030w-Iu for submit@debbugs.gnu.org; Tue, 21 Feb 2017 18:23:03 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:49783 helo=homiemail-a17.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cgJlu-00030Z-ED for 25751-done@debbugs.gnu.org; Tue, 21 Feb 2017 18:23:02 -0500 Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id 45A112B206D; Tue, 21 Feb 2017 15:22:57 -0800 (PST) Received: from localhost.linkov.net (m212-107-59-228.cust.tele2.ee [212.107.59.228]) (Authenticated sender: jurta@jurta.org) by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id 29C642B206A; Tue, 21 Feb 2017 15:22:55 -0800 (PST) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#25751: Query replace lazy highlighting Organization: LINKOV.NET References: <87mvdmxoig.fsf@lambda> <87wpcpx32v.fsf@localhost> <83d1ehxqzd.fsf@gnu.org> <87poig2zwg.fsf@localhost> <83mvdjrk6j.fsf@gnu.org> <87h93rcffj.fsf@localhost> Date: Wed, 22 Feb 2017 01:22:30 +0200 In-Reply-To: <87h93rcffj.fsf@localhost> (Juri Linkov's message of "Sun, 19 Feb 2017 01:17:04 +0200") Message-ID: <87mvdf164p.fsf@localhost> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 25751-done Cc: 25751-done@debbugs.gnu.org, antoine.levitt@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) >>> > I think the problem is not that we remove the highlight and add it >>> > anew, the problem is that there's a redisplay cycle in between the >>> > removal and the following addition. The fact that setting >>> > lazy-highlight-initial-delay alleviates the problem to some extent, >>> > but still leaves the flicker tells me that there's a call to sit-for >>> > or some such somewhere in the code that processes replacements, and >>> > the removal and addition of the highlight are on two different sides >>> > of that sit-for call. One possible solution would be to remove the >>> > highlight and add it without triggering redisplay, then I'd expect the >>> > flicker to go away. >>> > >>> > Does this make sense? >>> >>> This feature is called _lazy_ highlighting where _lazy_ implies that it's >>> intended to highlight matches much later after a lot of redisplay cycles. >> >> You could still leave the "lazy" part, if you both remove and re-add >> the overlays after the idle delay. IOW, the important thing is not to >> have redisplay between removal and addition of the highlight. > > That's an option too, and here is the tested patch (it sets > lazy-highlight-max-at-a-time to nil to avoid redisplay between > lazy iterations): Installed and closed. ------------=_1487719442-11674-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 16 Feb 2017 13:17:38 +0000 Received: from localhost ([127.0.0.1]:41776 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ceLwI-0007dx-4K for submit@debbugs.gnu.org; Thu, 16 Feb 2017 08:17:38 -0500 Received: from eggs.gnu.org ([208.118.235.92]:39170) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ceLwH-0007dk-3U for submit@debbugs.gnu.org; Thu, 16 Feb 2017 08:17:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ceLw5-00026s-Up for submit@debbugs.gnu.org; Thu, 16 Feb 2017 08:17:31 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:51701) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ceLw5-00026n-RV for submit@debbugs.gnu.org; Thu, 16 Feb 2017 08:17:25 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ceLw4-0004mb-HU for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2017 08:17:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ceLw1-00025Z-CI for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2017 08:17:24 -0500 Received: from mail-wr0-x230.google.com ([2a00:1450:400c:c0c::230]:33156) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ceLw1-00025L-5u for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2017 08:17:21 -0500 Received: by mail-wr0-x230.google.com with SMTP id i10so11474812wrb.0 for ; Thu, 16 Feb 2017 05:17:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:from:to:subject:date:message-id:mime-version; bh=x+xgEs3gBqXLBG9NFJtt3FUJ/UPdcxwl8Hi4N9lCUHg=; b=RMa2Fr2HLwydggb68pzG+8cRYY4giaehQ2gNOJhsGfIC2/CLFIzIug1W7D4g65x8NM xdJq/XN+RFM893bxBHiSECXLeMOpeiA2qrgPtYI81AJO33RWaie7lY13iT//YE0iQDL8 lKN7DCqNR49qyrgm1/jozSCVJi8gPcrSyim+8AwhM31Xx/mQw8ph6deZx1TeXkbK1A9V cG1Oi5nsCaf9z9/BuGOzSophv2TLKu0sunrPPg2NPa9saPxLdoNpTnu8OHyGuMdCeBQ5 jRzLcfFftC7ItqD7xHd9W2bTG9wmDs6DlgYJWqh/1Qw6Bq+HmTctSLCEAscS3J16B+2j zsFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:from:to:subject:date:message-id :mime-version; bh=x+xgEs3gBqXLBG9NFJtt3FUJ/UPdcxwl8Hi4N9lCUHg=; b=OEJgHFYHveb9ysOkbATzrbjudYupfIKzY/3ocVuoQ/omHxXZfGGn8a/I4gALDX/HiS tELVivGACwuWCeWZgn0rPB7ke41brpfdzQQIvNMzG6wrFoaVQrVU7TcSuzNG67S2Y6IP kJ2BspAPqo9gRCFlUYPSMwI9bff5Noiv76PhStjUQmAJNVYc/SOQ9uyqouIiXZsVd3gA ZuG/7t3jGJsAJQsgibRyqDNx52tNvnyjTch5F6+nk5YIRXGRRxeH8DreZYp6oVVABnOY 5xGQbyQd95DnZRRxhOAWKhckU9lpCmGPbHpsnjiGypvzKLwHlqtELTJR9LZiReHA8tdk FBew== X-Gm-Message-State: AMke39nwVOTHk5e1mvpzAeEeOzndhxMTpbxX1+rlqwhXNfGlAmcpKYOAgZ2rvoaBjv5K5w== X-Received: by 10.223.133.220 with SMTP id 28mr2440543wru.97.1487251039770; Thu, 16 Feb 2017 05:17:19 -0800 (PST) Received: from lambda (fw.enpc.fr. [194.57.247.3]) by smtp.gmail.com with ESMTPSA id 45sm8913965wrx.60.2017.02.16.05.17.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 05:17:18 -0800 (PST) User-agent: mu4e 0.9.17; emacs 26.0.50.1 From: Antoine Levitt To: bug-gnu-emacs@gnu.org Subject: Query replace lazy highlighting Date: Thu, 16 Feb 2017 14:18:31 +0100 Message-ID: <87mvdmxoig.fsf@lambda> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) (apologies if this has been posted before, but I can't find any references) When query-replacing and confirming, matches get unhighlighted, and then highlighted again, which is very distracting. E.g. open a file, M-% a -> a, y, other matches of a get unhighlighted then highlighted again. (setq lazy-highlight-initial-delay 0) (shouldn't it be default by the way, at least on graphical displays?) reduces the problem but does not eliminate it (it produces small flickers). There's lazy-highlight-cleanup, but that disables cleanup completely, which I don't want. Can't this be eliminated? Best, Antoine ------------=_1487719442-11674-1--