GNU bug report logs - #25751
Query replace lazy highlighting

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Juri Linkov <juri <at> linkov.net>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#25751: closed (Query replace lazy highlighting)
Date: Tue, 21 Feb 2017 23:24:01 +0000

[Message part 1 (text/plain, inline)]

Your message dated Wed, 22 Feb 2017 01:22:30 +0200
with message-id <87mvdf164p.fsf <at> localhost>
and subject line Re: bug#25751: Query replace lazy highlighting
has caused the debbugs.gnu.org bug report #25751,
regarding Query replace lazy highlighting
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
25751: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=25751
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Antoine Levitt <antoine.levitt <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Query replace lazy highlighting
Date: Thu, 16 Feb 2017 14:18:31 +0100

(apologies if this has been posted before, but I can't find any
references)

When query-replacing and confirming, matches get unhighlighted, and then
highlighted again, which is very distracting. E.g. open a file, M-% a ->
a, y, other matches of a get unhighlighted then highlighted again.

(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?

Best,
Antoine

[Message part 3 (message/rfc822, inline)]

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25751-done <at> debbugs.gnu.org, antoine.levitt <at> gmail.com
Subject: Re: bug#25751: Query replace lazy highlighting
Date: Wed, 22 Feb 2017 01:22:30 +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.
>
> 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):

Installed and closed.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.