[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#45898: 27.1; wedged in redisplay again
From: |
Stefan Monnier |
Subject: |
bug#45898: 27.1; wedged in redisplay again |
Date: |
Wed, 22 Jun 2022 19:39:14 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
> Isn't there a way to limit what font-lock considers a "line" such that
> it doesn't consider more than some number N of characters? What could
> potentially happen if we set N to, like, 10,000 characters?
Misfontification around that boundary.
> Are you saying that many regular expressions in font-lock-keywords are
> anchored at beginning or end of a line?
No but for example if the 10000 char boundary falls in the middle of the
word "function", then all the highlighting rules which rely on matching
the keyword "function" will fail.
> And even if the regexp-based font-lock needs to do it line-by-line,
> does it really _have_ to invoke parse-partial-sexp for the entire
> line, when doing syntactical fontifications? why is that?
AFAICT this is a call that does
(parse-partial-sexp (point) end nil nil state 'syntax-table)
where `end` happens to be point-max (because of font-lock's rounding up
to whole lines) which will not itself parse all the way to `end` but
will instead stop at the next string/comment boundary. This is used
(inside a loop which will indeed go all the way to `end`,
i.e. `point-max`) to highlight strings and comments (as you can see
from the stack trace, this is `font-lock-fontify-syntactically-region`).
For such huge files, it's arguably more important to be more-or-less
usable than it is to get the highlighting right, so there's a good case
for turning off font-lock or breaking it somewhat by using arbitrary
limits in the handling of `font-lock-extend-region-functions` in
`font-lock-default-fontify-region`.
Stefan
- bug#45898: 27.1; wedged in redisplay again, (continued)
- bug#45898: 27.1; wedged in redisplay again, Lars Ingebrigtsen, 2022/06/13
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/13
- bug#45898: 27.1; wedged in redisplay again, Phil Sainty, 2022/06/13
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/14
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/18
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/20
- bug#45898: 27.1; wedged in redisplay again, Stefan Monnier, 2022/06/20
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/21
- bug#45898: 27.1; wedged in redisplay again, Stefan Monnier, 2022/06/21
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/21
- bug#45898: 27.1; wedged in redisplay again,
Stefan Monnier <=
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/23
- bug#45898: 27.1; wedged in redisplay again, Stefan Monnier, 2022/06/23
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/24
- bug#45898: 27.1; wedged in redisplay again, Gerd Möllmann, 2022/06/25
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/25
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/25
- bug#45898: 27.1; wedged in redisplay again, Gerd Möllmann, 2022/06/25
- bug#45898: 27.1; wedged in redisplay again, Gerd Möllmann, 2022/06/25
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/25
- bug#45898: 27.1; wedged in redisplay again, Gerd Möllmann, 2022/06/25