[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#25751: Query replace lazy highlighting

From: Eli Zaretskii
Subject: bug#25751: Query replace lazy highlighting
Date: Fri, 17 Feb 2017 08:37:26 +0200

> From: Juri Linkov <address@hidden>
> Date: Thu, 16 Feb 2017 23:01:28 +0200
> Cc: address@hidden
> > (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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]