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

Previous Next

Full log

Message #296 received at 56682 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Thu, 28 Jul 2022 18:40:26 +0000

>> And it is the fundamental problem, because it means that all display 
>> routines have to deal with a very large amount of data.
>
> By multiplying a very long and truncated line enough times you can 
> always make Emacs useless.  The speedups I have in mind scale linearly 
> with the number of such lines, so eventually, with enough such lines, 
> Emacs will always become very slow at some point, especially if the 
> window is hscrolled very far to the right.
>

That's exactly my point: with long and truncated lines Emacs can become 
unusable with a 20 MB file, with long lines Emacs does not become unusable 
even with a 1 GB file.  And what I (and everybody I guess) wants is a 
"full and complete" solution.

>> Okay, so I'll wait a bit more.  I'd like to reach a conclusion as to 
>> whether truncate-lines should be turned off when 
>> long_line_optimizations_p is on before merging the branch into master.
>
> That's unrelated.  The branch was created for your work on font-lock, 
> and if you are done with that, feel free to land it on master.  I can 
> continue working on master, and/or will create a feature branch if I 
> feel it's justified.
>

It's not unrelated, at least not in my mind.  The branch was initially 
created to fix the remaining font-lock related issues, but this thread 
discusses, and the branch contains, fixes to the other remaining issues. 
I don't want to close this bug without a "full and complete" solution, and 
currently someone who has (setq truncate-lines t) in their init file or 
who presses C-x x t will see Emacs become unusable with a file with long 
lines.

What about the following course of action: I add a "disable truncate-lines 
in buffers with long lines" feature, and you remove it/disable it/make it 
optional later if/when you consider that your fixes make Emacs fast enough 
with long-and-truncated lines.  And we can/should open a new bug report 
and branch to discuss these long-and-truncated lines issues and solution 
attempts.

Previous Next

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