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 #508 received at 56682 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Mon, 01 Aug 2022 03:02:26 -0400
>>> That's true, but with such big files, the initial scan is slow.  So the
>>> scenario is simple: you open a big enough file, type M->, and C-p. M->
>>> will be instantaneous, and C-p will take a while, because of syntax-ppss.
>> Really?  I'd expect that `M->` is slow because of `syntax-ppss` (called by
>> font-lock) and then `C-p` is instantaneous.
> Yes, really.  M-> is fast because syntax-ppss is called inside
> fontification-functions, which are evaluated in a small portion of the
> buffer (with locked narrowing).

Ah, you're talking about a file with a long line.  I was thinking of just
a normal large file.

> And C-p is slow because post-command-hook is (or rather was) not
> subjected to the same locked narrowing.

I wonder what `C-p` has to do with `post-command-hook`.
After all, that same `post-command-hook` is also run after `M->` as well.


        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.