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

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

> > You clearly do not want this done.
> 
> Not at all.  I only disagree that it's a bug.

Good to hear.  But it sure didn't sound like it:

  J >>> There is no need to highlight all matches in the buffer
  J >>> during Isearch.
  E >> What if someone wants to?
  J > Why would someone want such a strange thing?

Anyway, I'm glad you agree now that such a strange thing can be useful.

> ‘lazy-highlight-max-at-a-time’ is just an optimization variable
> along with ‘lazy-highlight-initial-delay’, ‘lazy-highlight-interval’
> that users might want to tweak to improve performance where nil of
> ‘lazy-highlight-max-at-a-time’ allows highlighting in one loop
> that avoids delays on fast processors (it makes sense to change
> its default value to nil to match the modern hardware).
> 
> A new feature to highlight the whole buffer would be useful as well
> to reduce flickering during Isearch.  Currently when e.g. scrolling
> by one line lazy-highlight clears all matches on the screen, and
> re-highlights them with an additional line taken into account.
> That's because lazy-highlight is non-incremental.

Whole buffer OR rest-of-buffer forward or backward.  Au choix.
Both behaviors are useful.

> Highlighting the whole buffer could fix this visual effect.
> So unlike the current screen-limited lazy-highlighting that reacts
> to window-start/window-end changes, once whole-buffer lazy-highlighting
> finds all matches in the buffer it doesn't need to re-highlight them
> during Isearch navigation.
> 
> A new option could be named e.g. (defcustom lazy-highlight-buffer nil)
> Again, its default value is depending on the average hardware.
> While I believe that highlighting all matches on the screen
> is suitable for most users, I'm not sure about highlighting
> all matches in a (possibly large) buffer in one loop.

It's not clear how you see the two options interacting (or not).

If you are telling Isearch to highlight all matches and you are
also telling it to highlight at most 10, for example.  And what
about the current nil value of `lazy-highlight-max-at-a-time',
which also says (currently) that it means highlight "all"?

Not clear why you want a separate option for this.  It cannot be
used in combination with `lazy-highlight-max-at-a-time', can it?

If the behaviors are mutually exclusive, then why not just add
another value or two for `lazy-highlight-max-at-a-time'?

A second question concerns how to control whether this acts
only in the current search direction or in both directions.

In the patch I sent, a user gets all matches in the search
direction.  If s?he wants all matches in both directions it is
enough to briefly hit the other direction key (e.g. hit `C-r'
if searching forward).

The use I make of the all-matches behavior will be togglable, 
and I will want to control what the behaviors toggled are.

For exmaple, I might want a toggle between max=10 and
whole-buffer.  Or between whole-buffer and remainder-of-buffer
(in search direction).

> > whether it's searching within the active region (not needed,
> > since a user can always narrow the buffer);
>
> Because it's more useful to extend the bounds of the active
> region using Isearch.

Dunno what that means.  Please elaborate.  And please say why
you think it is always more useful than limiting search to the
region.

Whatever you mean by it, why should it be a question only of
design-time either-or?

In Isearch+, limitation of search to the active region is
optional, and you can change the behavior anytime on the fly
(toggle `C-x n').  (Deactivation of the active region is also
optional.)

> > search within text- or overlay-property zones;
> 
> There is an unfinished feature request bug#15245.

On-demand replacement of search hits is available in Isearch+.
At the time I replied in that bug thread, I guess I had not yet
added this feature.  It seems I added it a month after I posted
there.  Anyway, that too is available.  AFAIK, with Isearch+ you
can do all that is requested in the bug.

And as you say in the bug thread, you can also limit
`query-replace' to such text zones using `isearch-filter-predicate'.

> > on-demand replacement of search hits during search
> 
> Can you find a bug# for this?

It's not a bug, AFAIK.  It's an Isearch+ feature.
http://www.emacswiki.org/emacs/IsearchPlus#isearchp-replace-on-demand

You can perform an arbitrary action on the current search hit,
on demand.  By default, the action is replacement.

> > Please at least fix the doc so that it matches what the
> > code does, whether or not that matches what the original
> > intention was.
> 
> Then the docstring could point to the new option
> ‘lazy-highlight-buffer’.

See above.  I'm all for adding the ability to highlight beyond
the current window, and I am glad to hear you are also for it.

But it's unclear why a separate option should be used, instead
of additional option values for `lazy-highlight-max-at-a-time'.

And it's unclear how a user can get up-to-the-buffer/region-limit
behavior in one direction only.