bug#25751: Query replace lazy highlighting

[Eli Zaretskii <eliz@gnu.org>]

> From: Juri Linkov <juri@linkov.net>
> 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?