Subject: Re: bug#25751: Query replace lazy highlighting

From: Juri Linkov <[email-masked]>
Date: Mon, 20 Feb 2017 02:30:06 +0200

>> > 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 ‘M-x highlight-regexp RET a RET RET’