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 #68 received at 56815 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 56815 <at> debbugs.gnu.org, gregory <at> heytings.org, larsi <at> gnus.org
Subject: Re: bug#56815: 29.0.50; Isearch lazy-highlight highlights too much
 when truncate-lines is in effect
Date: Sun, 14 Aug 2022 16:53:50 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: gregory <at> heytings.org,  larsi <at> gnus.org,  56815 <at> debbugs.gnu.org
> Date: Mon, 01 Aug 2022 21:09:05 +0300
> 
> > 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.)
> 
> Exposing the "long-lines" flag to Lisp is exactly what is needed.
> So when lazy-highlight will detect a special value of a new
> buffer-local variable when narrowing is in effect due to long lines,
> then lazy-highlight can switch to a different algorithm
> like you described earlier.  Currently isearch-lazy-highlight-new-loop
> checks for window-group-start and window-group-end.  But when
> the "long-lines" flag is set, it should also check for window-hscroll
> because narrowed lazy-highlighting should be updated on hscrolling.
> 
> This "long-lines" flag will be also useful for pre-command-hook
> and post-command-hook to convey the information about narrowing
> to hooks.

You can now use the new long-line-optimizations-p predicate for that.
Although from your description above, perhaps Isearch should behave
like that in a buffer with line-truncation regardless of the long
lines.

Previous Next

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