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

[Eli Zaretskii]

> Date: Fri, 29 Jul 2022 19:52:08 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: juri@linkov.net, larsi@gnus.org, 56815@debbugs.gnu.org
> 
> > 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.
> 
> And you really think it's TRT to add such a special-purpose algorithm for 
> that very specific "long-and-truncated lines" case everywhere in Emacs? 
> Because isearch is just one example, there are many other places where you 
> will similarly need to reduce the portion of the buffer that will be 
> considered by the command to the portion of the buffer that is actually 
> visible on screen.

Which other places?

In this bug we are talking specifically about isearch.el adding
thousands of overlays to a buffer, 99.99% of which are not visible.
If there are other features that do something similar, please name
them.

And yes, if we want truncate-lines to work reasonably well, we need to
fix any features which behave silly in that display mode.  We will not
remove truncate-lines from Emacs, and we will not make it
dysfunctional.  But let's begin by discovering those features, so that
this discussion could be less academical.