bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#56682: Fix the long lines font locking related slowdowns


From: Eli Zaretskii
Subject: 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@gnu.org>
> Cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, larsi@gnus.org,
>  monnier@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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]