GNU bug report logs - #25751
Query replace lazy highlighting

Previous Next

Package: emacs;

Reported by: Antoine Levitt <antoine.levitt <at> gmail.com>

Date: Thu, 16 Feb 2017 13:18:01 UTC

Severity: minor

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 25751 <at> debbugs.gnu.org, antoine.levitt <at> gmail.com
Subject: bug#25751: Query replace lazy highlighting
Date: Mon, 20 Feb 2017 02:30:06 +0200
>> > 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):
>
> How does this relate to what has been discussed so far in bug #21092?

I'm sorry to say that, but setting lazy-highlight-max-at-a-time to nil
in the patch here in bug#25751 is a better way to avoid flicker
than highlighting all matches in the buffer as it was discussed
in bug#21092.

I believe that modern hardware can quickly highlight all matches
on the screen in one loop without a noticeable delay.  But highlighting
matches in the whole buffer is another thing.  Could you try to see
how fast this could be by trying to highlight a single character
in a large buffer, e.g. with ‘M-x highlight-regexp RET a RET RET’




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.