GNU bug report logs - #56682
Fix the long lines font locking related slowdowns

Previous Next

Full log

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 56682 <at> debbugs.gnu.org, larsi <at> gnus.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Mon, 01 Aug 2022 12:51:47 +0000

>
> You can see in the sources that both init_iterator and start_display are 
> many times called with 'struct it' that was used by the caller, so it 
> could already have the narrowed_begv and narrowed_zv members initialized 
> by the caller.  If we discover that we want to recalculate these values, 
> we'd then need to restore the previous value before we return, so that 
> the caller will see the same values it used before the call.  But we 
> have no easy way of doing that, and moreover, cannot even detect that 
> these members were initialized.  The inability to detect that they were 
> initialized is due to the fact that we don't initialize 'struct it' 
> before we call init_iterator, and so these fields can originally have 
> any arbitrary value.
>

Thanks, it's much clearer now.

>
> Which means, for example, that tests like this:
>
>  if (current_buffer->long_line_optimizations_p)
>    {
>      if (!it->narrowed_begv  <<<<<<<<<<<<<<<<<<<<<<<<<<
>         || ((pos.charpos < it->narrowed_begv || pos.charpos > it->narrowed_zv)
>             && (!redisplaying_p || it->line_wrap == TRUNCATE)))
>
> are not necessarily reliable, because we never initialize narrowed_begv 
> to zero, AFAICT.  Right?
>

Indeed.  That wasn't a problem with the previous code in which 
narrowed_begv was unconditionally assigned.  Now it is.  I think the 
following change should be enough to fix this.  Agreed?

diff --git a/src/xdisp.c b/src/xdisp.c
index 8a19b3bda9..9574d06bd5 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -3472,6 +3472,9 @@ init_iterator (struct it *it, struct window *w,
                        &it->bidi_it);
        }

+      if (current_buffer->long_line_optimizations_p)
+       it->narrowed_begv = 0;
+
       /* Compute faces etc.  */
       reseat (it, it->current.pos, true);
     }

>
> The other part of my reasoning is that callers of the display code which 
> are outside redisplay could legitimately move the iterator far from 
> point: think about pos-visible-in-window-p and its ilk.  So, when we are 
> not called by redisplay, I think it would be preferable to update the 
> narrowing due to these considerations.
>

Thanks, this too clarifies what you meant.

Previous Next

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