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: Sun, 31 Jul 2022 22:06:01 +0000


Emacs is not in the business of preventing people from shooting themselves in the foot. If we need this narrowing to be enforced because Emacs would otherwise crash, then it's OK, but if not, then we *should* provide a way to undo it.

And how do you define "crash"?

Core dump.


Aha, interesting! So an infinite loop is not a crash, according to that definition?

Is Emacs becoming unresponsive because an operation takes say two minutes to complete and cannot be interrupted a "crash"? Or is a "crash" only a segfault?

Try `M-: (use-global-map (make-keymap)) RET`

Should we prevent users from doing that?


It's a misleading question. No "user" would ever do that. Sure, it's a nice example, but only an Elisp hacker would do that, in the middle of a debugging session, and they would do that on purpose (although perhaps without knowing the effect in advance). Which has nothing to do with a regular user who just opens a file.


Let's focus on making it easy to make it work well, rather than making it impossible to make it work poorly.


You lost me here. I've read that sentence twenty times, and cannot understand what you mean.

But you didn't answer my question: is it not possible to design a version of syntax-ppss that would approximate, with some heuristics, what syntax-ppss does, but on a smaller chunk of the buffer?

The answer is basically "no" but even before getting there, I have to remind the reader that it hasn't really been requested.


It has, now 😉 Not "requested", however. I respectfully, with all due respect, ask whether doing such a thing would be possible.


In order to know if POS is within a string (which is one of the main uses of `syntax-ppss`), you basically need to know if there's an odd or even number of quotes before POS, which fundamentally needs to look at all the chars between POS and BOB. Of course we use a cache to try and avoid looking at them over and over again, but the cache can't be of any use the first time around.


But if you use heuristics, as I said, you don't need to look at all the chars between BOB and POS. You try your best to guess, on a small (a few kilobytes) portion of the buffer, where the strings most likely start and stop. And if you're only right in 95% of the cases, that's more than fine.
reply via email to

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