Subject: bug#25751: closed (Re: bug#25751: Query replace lazy highlighting)

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 21 Feb 2017 23:24:02 +0000

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 [email-masked].

-- 
25751: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=25751
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#25751: Query replace lazy highlighting
From: Juri Linkov <[email-masked]>
To: Eli Zaretskii <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Wed, 22 Feb 2017 01:22:30 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

>>> > 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.

Subject: Query replace lazy highlighting
From: Antoine Levitt <[email-masked]>
To: [email-masked]
Date: Thu, 16 Feb 2017 14:18:31 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

(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