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

[Eli Zaretskii <eliz@gnu.org>]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  larsi@gnus.org,  56815@debbugs.gnu.org
> Date: Sun, 31 Jul 2022 22:40:22 +0300
> 
> >> 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.
> 
> Do you think introducing the rectangular narrowing could be a more general fix?
> We already have rectangular regions generalized as non-contiguous regions.
> Could non-contiguous narrowing help to restrict the accessible buffer area
> to the visible screen rectangle?

I don't understand how such a restriction will work on the level of
buffer text.  E.g., what happens when you insert a single character
before the beginning of one of the narrowed regions? does the region
move with the text or does it stay on the same buffer positions?

Basically, as long as Emacs represents buffer text as a single long C
string (aside of the gap), with no additional structure, I don't see
how implement this with any reasonable complexity.

And I agree with Gregory that the gains in this case will be too low,
relative to the complexity.

Let's keep this in its correct proportions: we "just" want isearch to
behave reasonably well in long-and-truncated lines, because IMO
isearch is one of the few features that we cannot break or disable in
such buffers -- the ability to search is too fundamental to editing,
even if that editing means just viewing the text.

So if no good ideas arise that are simple enough to implement, I'm
okay with simply disabling isearch-lazy-highlight in such buffers, as
I wrote in the original bug report.  (Doing that will probably require
exposing the "long-lines" flag to Lisp, but that's fine by me.)

Thanks.