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

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

> > > 1. emacs -Q
> > > 2. Visit a file - anything other than a tiny one will do.
> > > 3. Use `customize-option' to set `lazy-highlight-cleanup' to nil
> > >    and set `lazy-highlight-max-at-a-time' to nil.
> > > 4. Search once for a simple string that occurs multiple times throughout
> > >    the buffer - e.g., `C-s the RET`.
> > > 5. Scroll down to see that the matches were not highlighted throughout
> > >    the buffer.  `lazy-highlight-max-at-a-time' does not work as
> > >    advertised.
> 
> What do you mean by "scroll down" in step 5 above?  Scroll down how?

C-v or whatever.  (Yes, this will exit Isearch,)

> Scrolling (as any other command that exits I-search) removes all
> highlighting, at least by default.

No, it does not.  Not if `lazy-highlight-cleanup' is nil - see step 3.
That's the point of that option, and of this bug report.

> And "all matches" in the
> variable's doc string means "all matches shown on the screen",

How could that be?  What's the point of the option value of nil -
or even a large value - in that case?  And why would we bother to
warn that a large (let alone a nil) value can make things slow, if
highlighting is always limited to what is visible "on the screen"?

How big a screen would someone have to have, to make any
consideration of performance important, if nil is _supposed_ to
highlight only all matches "on the screen"?

Where do you get your interpretation of "all matches"?  From the
display-engine code, I guess, but certainly not from the doc or the
Customize UI, which says just "All".  All matches means all matches;
it does not mean all matches that fit some unmentioned criterion.

> as the display engine never does anything beyond the displayed
> portion (that's a simplification, but it will do for the purposes
> of this discussion).

That description of the display-engine _implementation_, which I
don't doubt, does not jibe with the description of the option.

And as the description is quite deliberate about the possibilities
and behavior of both a LARGE value and a nil value, and about the
consequent risks to performance, it would seem that the _design_
of this feature does not fit the display-engine implementation.

Am I missing something else?  What's the point of such a design
(and its consequent doc), if it could _never be realized_ because
of display-engine limitations?  (I don't doubt the display-engine
design or implementation.  The question is about how this design
could possibly work, given the display engine as you say it is.)

Something else puzzles me.  I did not have the impression that
there was such a hard-and-fast display limitation.  Am I mistaken
that we have no problem forcing the display engine to font-lock
fontify a whole buffer, regardless of size?

If that is possible (I am thinking it is possible, but I could be
wrong) then why would it not also be possible to put lazy-highlight
highlighting on a whole buffer, regardless of size?  And I can call
a homemade function that highlights stuff throughout a LARGE buffer,
whether using font-lock or otherwise.  No problem, AFAICS.

Wrt the actual behavior I see: a nil value seems, indeed to have
no effect beyond the text that has already been shown.  That's
really too bad.

(And lazy highlighting, beyond just highlighting, also computes
all search matches, which can be useful.  But perhaps you will
say that it computes only all matches on the screen?)

I do hope that someone takes a close look at this and you don't
just dismiss it.

AFAICT, it is possible to highlight text throughout a buffer, even
a VERY large one, and using either overlays or text properties.
IOW, I don't understand - I don't think I see the display-engine
limitation you seem to be saying is in place.

IIUC, a lot has changed since lazy highlighting and these options
were first introduced - jit-lock, etc.  Perhaps this worked at one
time, and a regression was introduced since then?  (No, I don't see
that myself - the same bug is in Emacs 22.3.)

Or are you absolutely convinced that this could never have worked,
because of the way the display engine works?  If so then I'm quite
disappointed, but in that case please at least correct the doc
and the Customize UI, to make clear that the value (numeric or nil)
has no effect beyond what is/has been shown on the screen - that it
is not at all about highlighting "all matches".

And given that Lisp code apparently _can_ highlight a whole, large
buffer (AFAICT), if you have any tips on how I might make this work,
myself, for Isearch lazy highlighting, please pass them along.