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

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

> >> Are you sure this should be part of isearch, not hi-lock?

Yes, as I said.  And I gave several reasons.

> hi-lock is not about font-lock highlighting too
> when font-lock is not active.  See the variable
> ‘hi-lock-highlight-range’ with its default limit of 200000.
> 
> I'm thinking about using lazy-highlight in hi-lock
> to overcome this limitation after adding support
> for full-buffer to lazy-highlight.  Maybe better
> to generalize the current implementation of
> isearch-lazy-highlight-update to apply a function
> given as an argument to perform different actions
> on the found matches (by default, adding the lazy-highlight
> overlay, and for hi-lock adding the hi-lock-overlay).

A hi-lock feature doesn't correspond at all to what I
requested for this enhancement.  I specifically want
this as a feature of Isearch, for the reasons I gave.

I guess I'll need to do this for only my own code.
It's easy enough to do.  I was hoping not to have to
maintain yet another difference from vanilla Isearch,
and to give vanilla Isearch the same potential benefits.

Sorry I mentioned it now.  After you do what you will
do it will increase my maintenance burden rather than
lessening it, and it won't move vanilla Emacs in the
same direction.

I already provide users a way to act on the current
search hit in arbitrary ways.  The default action is
replacement - the default replacement is "" (delete).

Your way of providing something similar will no doubt
not offer exactly the same thing, and will anyway not
use the same approach of implementation.

No good deed goes unpunished, I guess.  I suppose I
should be happy to have inspired an improvement in
Emacs, even if it's not the improvement I requested.