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

[Drew Adams <drew.adams@oracle.com>]

> > > IOW, I would like nil to behave as advertised: no limit.  This is the
> > > use case that prompted me to file the bug and look for a solution.
> >
> > There is no bug.  I have ‘lazy-highlight-max-at-a-time’ set to nil
> > in my .emacs for years, and it worked as intended to optimize the
> > performance of the screen-limited lazy-highlighting.  Please don't break
> > this useful option.  With your proposed changes Isearch will be horribly
> > slow to highlight all matches in a large buffer on every search state
> > change.
> >
> > There is no need to highlight all matches in the buffer during Isearch.
> 
> What if someone wants to?
> 
> > If you want a new feature, please create a new feature request
> > with a subject like ‘Feature request: lazy-hi-lock on Isearch exit’
> > that will highlight all matches in the buffer after you exit Isearch.
> 
> How about leaving the current meaning of nil as it is, i.e. limit the
> highlighting to the visible portion of the buffer, and introducing a
> special value like zero or -1 to mean highlight the whole buffer?

As I said earlier, I'm all for adding additional specific arguments
for different behaviors - whatever is needed.

But "the current meaning of nil", as it is documented, is not what
the behavior is.  I respect Juri's argument that the bug is quite
old and that some people might be used to nil not doing what has been
advertised for it and want it to continue doing what it has long been
doing.  That's a reasonable argument.

Personally, I would prefer that nil be made to act as advertised, but
it is OK with me if the decision is to keep the nil behavior as it is
now, and so change its meaning from what is currently documented (IOW,
change the doc and Customize UI so that they fit what nil currently
does), as long as there is some (new) value for the option that does
what the doc has been saying nil does: highlight all search hits -
no limit on the highlighting.

I don't care whether you call this a new feature or a bug fix.
To me it is a bug fix, as indications are that the fixed behavior
was the originally intended behavior.  But who really knows?  It
doesn't matter to me what we call it.

To me it is very useful to be able to have lazy highlighting
highlight all search hits.  To mention a use case, in case it makes
any difference to you:

I have code that lets you hit a key to search again (different
search pattern) during the same or a subsequent Isearch invocation,
and have this second search be limited _within_ the previous
search hits.  That is, the lazy-highlight zones from one search act
as the search contexts (limits) for the next search.  You can
repeat this etc.

This is a kind of progressive narrowing.

And I have code that lets you search within defined areas (think
of multiple regions), and there too you can hit a (different)
key to refine the search.  In this case, whole contexts that did
not have a search hit from the first search are removed as
candidates for the next search.  IOW, the current search hits
narrow the set of contexts for subsequent searching.

This is another kind of progressive narrowing.

In both cases, subsequent searches may well hit places that
were offscreen during previous searches, because the addition
of constraints (reduction of contexts) can reduce the matches.

In this use case, it can be (and typically is) useful to
lazy-highlight all search hits and (typically) to turn off
`lazy-highlight-cleanup'.