bug#56815: 29.0.50; Isearch lazy-highlight highlights too much when truncate-lines is in effect

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 29 Jul 2022 19:11:10 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: juri@linkov.net, larsi@gnus.org, 56815@debbugs.gnu.org
> 
> > I think posn-at-point is much faster,
> >
> 
> No, it is slower.  On my laptop, with long-line.xml and truncate-lines:
> 
> (benchmark-run 1000 (pos-visible-in-window-p 310000)) takes 4 seconds
> 
> (benchmark-run 1000 (numberp (cadr (posn-at-point 310000)))) takes 6 seconds

Why does it matter how long pos-visible-in-window-p takes when it
cannot tell whether the position is visible?

As for posn-at-point, 6 msec per position is not bad, if we in
addition limit the number of matches by some reasonable number, like
100, say.

Moreover, isearch.el could use some special-purpose algorithm for
looking for visible matches in this case.  For example, as soon as
posn-at-point tells us a match is to the right of the window's right
edge, isearch.el could go to the beginning of the next line and
continue from there, instead of checking all the subsequent matches on
the same line (with a result that is known in advance).  This way, we
will probably have even fewer matches, and the search will be faster,
except for very large values of hscroll.