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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, dgutov <at> yandex.ru
Subject: Re: locked narrowing
Date: Wed, 17 Aug 2022 21:29:29 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: dgutov <at> yandex.ru,  56682 <at> debbugs.gnu.org,  gregory <at> heytings.org
> Date: Wed, 17 Aug 2022 13:58:21 -0400
> 
> > Why can't you simply use the same code maybe_produce_line_number uses
> > for that?
> 
> Because I can't find that code.

What do you mean? it's in maybe_produce_line_number, obviously...

> Apparently `maybe_produce_line_number`
> just uses `w->base_line_number` whenever it's not 0, so apparently it's
> set to 0 elsewhere.

It's set to zero in several places in xdisp.c.

But again, if you don't want to trust the cached values, just use
display_count_lines starting from BOB.

> > Why does it matter which line numbers you compute if they are never
> > displayed?
> 
> They may be displayed at some other time: nlinum-mode won't be invoked
> if that same portion of the buffer becomes visible later on (it's just
> like font-lock: the highlighting applied stays until something like the
> after-change-function causes it to be refreshed).

Then invalidate the information on that portion when the buffer
becomes displayed, and let the code count again.

Previous Next

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