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: gerd.moellmann <at> gmail.com, 56682 <at> debbugs.gnu.org, larsi <at> gnus.org, monnier <at> iro.umontreal.ca
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Sun, 31 Jul 2022 09:16:43 +0300

> Date: Sat, 30 Jul 2022 19:11:57 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: gerd.moellmann <at> gmail.com, 56682 <at> debbugs.gnu.org, larsi <at> gnus.org, 
>     monnier <at> iro.umontreal.ca
> 
> >> jit-lock--antiblink-post-command
> >
> > OK, but is it TRT to "punish" every one of these hooks for the "crimes" 
> > of the few?  Maybe we should instead handle the problematic ones 
> > locally, by exposing the long_line_optimizations_p flag to Lisp (through 
> > an accessor), and then modifying those that misbehave to "behave"?
> 
> It's the same problem than with fontification-functions.  We cannot know 
> what all these hooks that are installed by major and minor modes will do, 
> we cannot hope to fix them one by one, so it seems to me that with 
> long_line_optimizations_p, which is an unusual case anyway, it makes sense 
> to "punish" them all in the same way.

It sounds...too drastic.  Lars, WDYT?

I don't find it problematic to have to fix any such hooks in the core
that we discover as misbehaving with long lines.  How many of those
could we have?  And those in 3rd party packages can follow suit if
they want (and if the respective modes are relevant to files with long
lines, I expect to see pressure on their developers to do so).

Once again, IME it is impossible to fix such problems only in
low-level C infrastructure.  There will always be left-overs and
fallouts that should be fixed locally in Lisp where they happen.
There's no problem here, and I don't expect us to be able to fix
everything by a small number of quick fixes, and declare a victory
once and for all.

> Agreed.  My point was only that Emacs now behaves a bit better when 
> editing a single-line very large file compared to a multi-line very large 
> file.

Well, WDYT about a similar feature for very large files?  IOW, when
the buffer's size is above some threshold, turn on the
long_line_optimizations_p flag (which should perhaps be renamed to
better reflect its purpose) even if no long lines are seen?

Previous Next

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