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: Gregory Heytings
Subject: 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.





reply via email to

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