bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#56682: Fix the long lines font locking related slowdowns


From: Eli Zaretskii
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@heytings.org>
> cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, larsi@gnus.org, 
>     monnier@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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]