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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, dgutov <at> yandex.ru
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Mon, 01 Aug 2022 15:04:13 +0300

> Date: Sun, 31 Jul 2022 22:50:23 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, 
>     Stefan Monnier <monnier <at> iro.umontreal.ca>
> 
> It is way better to wait a few seconds more while the file is being
> opened than to wait before two basic motion commands when the file
> is already opened.

I don't think I agree.  Having to wait for the initial display is
pretty annoying.  In fact, this was how the original font-lock worked:
it was triggered by find-file, and would fontify the entire buffer
before showing any of it.  That led very quickly to the likes of
lazy-lock and fast-lock, and was eventually fixed by jit-lock.

Try visiting a very large file encoded in something of the ISO-2022
family, and you will see what I mean.  It's an annoyance.

I have jit-lock-stealth enabled because I don't like the initial wait,
but don't want any subsequent waits, either.  We also have the (little
used, for some reason) jit-lock-defer feature: if you set
jit-lock-defer-time to a large enough value, M-> followed by C-p will
not be as slow as they are now, I think.

Previous Next

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