Subject: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work

From: Eli Zaretskii <[email-masked]>
Date: Sat, 29 Aug 2015 10:07:44 +0300

> Date: Fri, 28 Aug 2015 14:43:11 -0700 (PDT)
> From: Drew Adams <[email-masked]>
> Cc: Eli Zaretskii <[email-masked]>, [email-masked]
> 
> Please see the simple patch I sent, which I think takes care of this.

If we are going to extend highlighting beyond the displayed portion of
the buffer, then your proposed patch needs more work, IMO.  AFAIU,
with your patch, setting lazy-highlight-max-at-a-time to, say, 2000,
will still limit the highlighting to the displayed portion, which
makes little sense to me, as the probability of finding more than 2000
matches in a single window-full is practically zero, and so the user's
intent will not be honored (and the doc string will still be
misleading).

Instead, I suggest to use a special non-nil value, e.g. zero or -1, to
indicate a limit to the current window's end, and treat any other
value literally, disregarding the window limits.  (This will need to
be reflected in the documentation, of course.)  That special value
should IMO be the default.  Or maybe introduce a separate predicate
option for whether to limit to window start and end.

Yes, this would be a backward-incompatible change, but I don't think
the difference will matter too much in most use cases, especially with
the default value of lazy-highlight-cleanup.

Btw, another issue that arises in this regard is whether to highlight
beyond the screen only in the direction of the search (which AFAICS is
what your proposed patch does) or in both directions, especially when
the value of lazy-highlight-max-at-a-time is nil.