GNU bug report logs - #25751
Query replace lazy highlighting

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Antoine Levitt <antoine.levitt <at> gmail.com>
Subject: bug#25751: closed (Re: bug#25751: Query replace lazy highlighting)
Date: Tue, 21 Feb 2017 23:24:02 +0000

[Message part 1 (text/plain, inline)]

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 <at> debbugs.gnu.org.

-- 
25751: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=25751
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25751-done <at> debbugs.gnu.org, antoine.levitt <at> gmail.com
Subject: Re: bug#25751: Query replace lazy highlighting
Date: Wed, 22 Feb 2017 01:22:30 +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.
>
> 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.

[Message part 3 (message/rfc822, inline)]

From: Antoine Levitt <antoine.levitt <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Query replace lazy highlighting
Date: Thu, 16 Feb 2017 14:18:31 +0100

(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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.