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

Previous Next

Full log

Message #29 received at 56815 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: larsi <at> gnus.org, 56815 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#56815: 29.0.50; Isearch lazy-highlight highlights too much
 when truncate-lines is in effect
Date: Fri, 29 Jul 2022 22:31:22 +0300

> Date: Fri, 29 Jul 2022 19:11:10 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: juri <at> linkov.net, larsi <at> gnus.org, 56815 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.