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

Previous Next

Package: emacs;

Reported by: Gregory Heytings <gregory <at> heytings.org>

Date: Thu, 21 Jul 2022 18:01:01 UTC

Severity: normal

Done: Gregory Heytings <gregory <at> heytings.org>

Bug is archived. No further changes may be made.

Full log

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

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

> Search in xdisp.c for "->base_line_number = 0", and you will see that
> we invalidate the cache when the narrowing changes or when other
> similar calamities happen.

OK, after another search I found (in `redisplay_window` and
`try_scrolling`) that we do:

	  if (!just_this_one_p
	      || current_buffer->clip_changed
	      || BEG_UNCHANGED < CHARPOS (startp))
	    /* Forget any recorded base line for line number display.  */
	    w->base_line_number = 0;

So IIUC `w->base_line_number` can be used if:

          w->base_line_number != 0
          && !current_buffer->clip_changed
          && BEG_UNCHANGED < w->base_line_pos

?

Why do we flush the cache when `just_this_one_p` is false?


        Stefan
This bug report was last modified 2 years and 8 days ago.

Previous Next

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