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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 56682 <at> debbugs.gnu.org, Gregory Heytings <gregory <at> heytings.org>, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Fri, 05 Aug 2022 09:17:21 -0400

> Do our users regularly edit 30MB files?

Thanks to Gregory's changes, it may start becoming more common.

> And do a lot of changes in them?

In my experience, not very much, no.  Usually large files are
machine-generated and rarely edited by hand.  But there are still
relevant use-cases like opening a large JSON/XML/younameit file and
applying a search&replace or a keyboard macro to it.

I think my machines are slow enough (and my Emacs has enough extra
sluggishness thanks to the many assertion checking compiled into it)
that I'd be better served with an approach like that of so-long where
large files use a dumbed down major mode to avoid most source of extra
slow down like font-lock.

What I'm not sure of is how useful is a "font-lock with arbitrary
narrowing", where portions will be highlighted as strings rather than
code (and vice-versa).  I don't have enough experience with it yet to
be sure.  Taking a step back, I suspect that the only "real" solution is
something like `jit-lock-defer` coupled with a way to perform the
font-lock (and syntax-ppss/propertize) in the background.


        Stefan

Previous Next

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