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


View this message in rfc822 format

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: bug#56682: locked narrowing
Date: Wed, 17 Aug 2022 15:38:46 -0400
> And another thought: did you try using format-mode-line as the means
> to get the line number from which you could start?

Yes, but in my tests, it wasn't any faster.

BTW, while I have now found which code flushes the base_line cache
during redisplay (there are a few different places, in
`redisplay_window` and `try_scrolling` (not sure why it needs to be
done at more than one place, tho)),
I still haven't found where that cache gets flushed or ignored for
the case where it's used for `format-mode-line`.  That code doesn't
seem to pay attention to BEG_UNCHANGED nor even to the changes
in narrowing.

Oh... wait... aha!  I still don't know how it handles buffer
modifications, but I now know that it just fails to pay attention to
changes to the narrowing: so, it's no surprised that I couldn't find the
corresponding flushing code, it's just missing:

    emacs -Q lisp/subr.el
    M->
    M-: (list (format-mode-line "%l")
              (save-restriction (narrow-to-region (+ (point-min) 4000) (point-max))
                                (format-mode-line "%l")))

returns twice the same line number.


        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.