bug#29360: 26.0; Add full-buffer choice for `isearch-lazy-highlight'

[Drew Adams]

> > See bug #21092 for the motivation and reasons behind this bug report.
> > The aim of that bug report was never taken care of, which was to let
> > you force lazy-highlight highlighting on the full visible portion of
> > the buffer (where that refers to the full buffer or the current
> > buffer restriction).  IOW, optionally do not restrict highlighting
> > to what is currently on screen, as is done now.
> >
> > The #21092 bug report mistakenly took a `nil' value of
> > `lazy-highlight-max-at-a-time' as meaning just that - just what the doc
> > said: act on the full buffer, not just on the text that is currently in
> > the window.  The true meaning of nil for that variable is just to
> > highlight all of the search hits visible in the window.
> >
> > This new bug aims to finally get what was really being requested in
> > #21092: the ability to cause lazy highlight to act on the full buffer,
> > not just the text currently visible in the window.
> >
> > The outcome of #21092 and other bugs led to the creation of variable
> > `isearch-lazy-highlight'.  At the end of #21092, realizing that closing
> > #21092 did not, in fact, respond to the aim of #21092, Juri suggested
> > that a separate report be filed, to request a new possible value for
> > `isearch-lazy-highlight' which will cause the full buffer to get the
> > lazy-highlight highlighting.  That is the purpose of this bug report:
> > please add such a `buffer' or `full-buffer' value.
> 
> Are you sure this should be part of isearch, not hi-lock?

Yes.

> Isearch used to highlight only the visible part of the buffer

Isearch also used to highlight only the current search hit -
no lazy-highlighting at all.  So what?  Did someone back
then argue that we shouldn't add lazy highlighting because
Isearch is only about finding the next search hit?  No.
Highlighting all visible hits is an improvement over the
pre-Emacs 22 behavior.  Being able to optionally highlight
all hits (visible in the window or not) adds other advantages.

> because it is modal and doesn't allow the user to scroll the
> current search match out of view. Whereas hi-lock is intended
> to highlight all matches in the whole buffer.

Just because Isearch has not previously had an option to
highlight all matches is not a reason it should not offer
such an option.  This is only about _optional_ behavior; it
proposes no change to the default lazy-highlighting behavior.

No relation to hi-lock. This is not about font-lock
highlighting.  It is about the "lazy-highlighting" 
of Isearch, during Isearch, for Isearch, being extended
to cover the whole buffer.  It is about incremental
search: being able to change the set of matches incrementally.

You can (now) set `lazy-highlight-cleanup' to nil (you can
even toggle it during Isearch) to keep the lazy-highlighting
when search is done.  That can be very useful.

And doing likewise without needing to totally exit Isearch
can also be useful, e.g., to search only _within_ the lazy
highlights - i.e., progressing search narrowing.  E.g,
combine multiple simple regexps (ANDing them) vs trying to
come up with a single, complex regexp to do the same thing.
Or being able to flip to searching the complement of the
lazy highlights.

Any such features expect, to be really useful, that the
lazy-highlighted zones include all of the search hits,
over the entire search space.  They are about a new
search that is related to the previous search.  They
should not be limited to whatever hits were visible in
the current window for the previous search.

Just because this is not the classic Isearch use case is
not a reason it isn't usefully added to Isearch.  It is
only about isearching - isearching zones that have been
found by isearching.  It's about isearching isearches...

Any argument about not being able to see highlighting past
the window is irrelevant - this is not about scrolling.

The motivation was already discussed in bug #21092.  That
bug should have taken care of this, but I expressed the
need in terms of `lazy-highlight-max-at-a-time', having
misunderstood that variable's purpose because its doc
string described, for a nil value, just what this bug
(#29360) asks for.