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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: gregory <at> heytings.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 16:45:03 +0300

> Date: Mon, 01 Aug 2022 16:24:00 +0300
> From: 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
> 
> > 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;
> > +
> 
> Sorry, I wrote that this is OK, but it isn't: if init_iterator is
> called with 'struct it' that was already initialized by a previous
> call to 'reseat', the above will nuke the narrowing.
> 
> So we need something more complicated.  ATM I don't see how to solve
> this without manually initializing narrowed_begv before the first call
> to init_iterator or start_display.  Hmm...

I think we should simply unconditionally recompute the narrowing in
'reseat'.  At least I couldn't think of a situation where that would
cause trouble, and 'reseat' is called rarely enough not to make this
expensive.  Am I missing something?

And another nit:

  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)))
	{
	  it->narrowed_begv = get_narrowed_begv (it->w, window_point (it->w));
	  it->narrowed_zv = get_narrowed_zv (it->w, window_point (it->w));
	}
    }

I think this should pass pos.charpos as the 2nd argument to
get_narrowed_begv and get_narrowed_zv, otherwise it might not really
correct anything, right?  In particular, when lines are truncated,
that will definitely happen when we display any line but the very
first.

Or perhaps we should check that using window-point indeed brings
pos.charpos into the narrowed region, and only use pos.charpos if it
doesn't?

Previous Next

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