[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: |
Sat, 18 Feb 2017 10:13:08 +0200 |
> From: Juri Linkov <juri@linkov.net>
> Cc: antoine.levitt@gmail.com, 25751@debbugs.gnu.org
> Date: Sat, 18 Feb 2017 00:52:47 +0200
>
> > 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.