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 20:26:00 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: larsi@gnus.org, 56815@debbugs.gnu.org, juri@linkov.net
> 
> > And yes, if we want truncate-lines to work reasonably well, we need to 
> > fix any features which behave silly in that display mode.
> 
> If we want truncate-lines to work reasonably well without fixing all such 
> features one-by-one, we need to fix the root cause of that dysfunction, 
> which is not inside these individual features, but is the fact that (- 
> (window-end) (window-start)) is huge.

I'm not convinced that this is the root cause, nor that there is
indeed a single cause.  So far we have found only one feature where
this is true, and even that is only because Isearch uses that
particular method of deciding when to produce the highlight overlays.

It is true that the narrowing optimizations work less well under
truncate-lines, for these reasons, but there are other places where we
can make improvements and other methods of doing that.

There's no reason to believe that the general issue of long lines can
be solved by a small number of changes that narrow the buffer.
Whatever is left after that we should try solving by other methods.

> > We will not remove truncate-lines from Emacs, and we will not make it 
> > dysfunctional.
> >
> 
> Nobody is asking or suggesting to remove truncate-lines from Emacs, or to 
> make is dysfunctional.  Admitting that it doesn't work together with long 
> lines, which has always been the case, is something entirely different.

I admit that it's a tougher nut that currently is not yet cracked,
yes.  But if improvements can be made in that mode, we should at least
try making them, even if those improvements call for some
complications in our code.