[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#45898: 27.1; wedged in redisplay again
From: |
Lars Ingebrigtsen |
Subject: |
bug#45898: 27.1; wedged in redisplay again |
Date: |
Mon, 13 Jun 2022 14:10:19 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Eli Zaretskii <eliz@gnu.org> writes:
> Here's the first cut. It still needs polishing and some testing, but
> let me know what you think:
[...]
> +/* Update the redisplay-tick count for a window, and signal an error
> + if the tick count is above some threshold, indicating that
> + redisplay of the window takes "too long".
Ah, instead of measuring the time elapsed, we use the number of iterator
"executions" as a proxy. That sounds promising.
One problem that occurs to me is if you're, say, only displaying a shell
buffer, and it's outputting data -- then I don't think we'll be changing
windows, but just accruing ticks? But I think that should be easy
enough to fix, since we'll be returning to command_loop and we could
just have that nixing out the tick count, too. Probably.
A different problem is when we don't have many ticks, but each tick
takes a long time to execute. The classic problem here is when we have
a font-locking regexp that's very complicated (with lots of
backtracking). Then we don't update anything on the screen much -- we
spend (virtually) all the time in the regexp matcher. I don't see an
easy fix to that using this scheme...
> For testing purposes, is it possible to have examples of files that
> could benefit from this feature, i.e. files where Emacs becomes not
> responsive enough? I'm not sure the few examples I have cover all the
> popular reasons for the slowness, as I think there are more than one
> or two.
I don't have anything handy... anybody else have a setup that will
freeze Emacs redisplay that we can test with?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
- bug#45898: 27.1; wedged in redisplay again, (continued)
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/09
- bug#45898: 27.1; wedged in redisplay again, Lars Ingebrigtsen, 2022/06/09
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/09
- bug#45898: 27.1; wedged in redisplay again, Lars Ingebrigtsen, 2022/06/09
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/09
- bug#45898: 27.1; wedged in redisplay again, Lars Ingebrigtsen, 2022/06/10
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/12
- bug#45898: 27.1; wedged in redisplay again, Lars Ingebrigtsen, 2022/06/12
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/12
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/12
- bug#45898: 27.1; wedged in redisplay again,
Lars Ingebrigtsen <=
- 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, 2022/06/22