[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: |
Mon, 01 Aug 2022 07:51:12 +0000 |
Your current code makes it impossible for a major mode to make Emacs
slow by widening in a too-long-line.
Which is a good thing, isn't it?
No: we don't want to prevent people from shooting themselves in the
foot. Basically if it says "impossible" there's a good chance it's not a
good thing.
Apparently you don't understand what I'm doing. I'm trying to make Emacs
handle exceptional cases gracefully, by:
1. adding as few hard limits as possible, and
2. keeping as many functionalities as possible (my task would have been _a
lot_ easier if I had just stopped after saying "just open these files with
M-x find-file-literally").
If you think there's anything wrong with that approach, I'll have to
conclude that we live on different planets. On Earth and on Theory,
maybe?
And no, it's not even "impossible" for Emacs uses to shoot themselves in
the foot, so your argument collapses. Those who prefer the "Traditional
Emacs Approach"™ when it encounters such exceptional cases, that is,
those who:
1. do not want to add any limits whatsoever in any circumstance, and
2. agree to take the risk of making Emacs completely unfonctional,
can simply add (setq long-line-threshold nil) in their init file.
I just sent one such example to Dmitry. And I pointed to another
possible solution, namely to scan the whole buffer while opening it
(instead of scanning it lazily, which is IIUC what currently happens).
From a user viewpoint, it's understandable that opening a big file
takes some time.
We used to scan eagerly in the background with `jit-lock-stealth`, but
that was not very popular (eats up your battery for fairly little
benefit). We also have "lazier" highlighting via `jit-lock-defer`, but
that hasn't been adapted to `syntax-ppss`. It might be worth
investigating.
It might be, indeed. But I will most probably not do that myself.
- bug#56682: Fix the long lines font locking related slowdowns, (continued)
- bug#56682: Fix the long lines font locking related slowdowns, Dmitry Gutov, 2022/08/02
- bug#56682: Fix the long lines font locking related slowdowns, Stefan Monnier, 2022/08/02
- bug#56682: Fix the long lines font locking related slowdowns, Gregory Heytings, 2022/08/02
- bug#56682: Fix the long lines font locking related slowdowns, Stefan Monnier, 2022/08/03
- bug#56682: Fix the long lines font locking related slowdowns, Gregory Heytings, 2022/08/03
- bug#56682: Fix the long lines font locking related slowdowns, Stefan Monnier, 2022/08/03
- bug#56682: Fix the long lines font locking related slowdowns, Gregory Heytings, 2022/08/03
- bug#56682: Fix the long lines font locking related slowdowns, Stefan Monnier, 2022/08/04
- bug#56682: Fix the long lines font locking related slowdowns, Po Lu, 2022/08/01
bug#56682: Fix the long lines font locking related slowdowns, Stefan Monnier, 2022/08/01
- bug#56682: Fix the long lines font locking related slowdowns,
Gregory Heytings <=
- bug#56682: Fix the long lines font locking related slowdowns, Eli Zaretskii, 2022/08/01
- bug#56682: Fix the long lines font locking related slowdowns, Dmitry Gutov, 2022/08/01
- bug#56682: Fix the long lines font locking related slowdowns, Eli Zaretskii, 2022/08/01
- bug#56682: Fix the long lines font locking related slowdowns, Dmitry Gutov, 2022/08/02
- bug#56682: Fix the long lines font locking related slowdowns, Gregory Heytings, 2022/08/02
- bug#56682: Fix the long lines font locking related slowdowns, Eli Zaretskii, 2022/08/02
- bug#56682: Fix the long lines font locking related slowdowns, Gregory Heytings, 2022/08/02
- bug#56682: Fix the long lines font locking related slowdowns, Dmitry Gutov, 2022/08/02
- bug#56682: Fix the long lines font locking related slowdowns, Dmitry Gutov, 2022/08/02
- bug#56682: Fix the long lines font locking related slowdowns, Gregory Heytings, 2022/08/03