GNU bug report logs -
#25751
Query replace lazy highlighting
Previous Next
Full log
Message #14 received at 25751 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Date: Thu, 16 Feb 2017 23:01:28 +0200
> Cc: 25751 <at> 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?
This bug report was last modified 8 years and 142 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.