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

[Juri Linkov <juri@linkov.net>]

> 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?
Isearch used to highlight only the visible part of the buffer
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.