[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#45898: 27.1; wedged in redisplay again
From: |
Eli Zaretskii |
Subject: |
bug#45898: 27.1; wedged in redisplay again |
Date: |
Sat, 25 Jun 2022 14:29:41 +0300 |
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Sat, 25 Jun 2022 13:10:14 +0200
> Cc: 45898@debbugs.gnu.org
>
> > You mean, just update_ticks? That's too general, IMO. I'd like
> > people to have an idea what that does when they just see the call.
> >
> > But I'm not good with names.
>
> I love update_ticks! And I'm good with names, trust me ;-). And I'm
> volunteering to do the work!
Fine with me, have fun.
> >> You mean a case, where small numbers of ticks sum up by calling these Lisp
> >> functions often enough?
> >
> > Actually, I meant something even simpler: a Lisp program that calls,
> > say, regexp search repeatedly, to accumulate enough ticks that would
> > signal an error, thus aborting that Lisp program.
>
> That's 100% what I also meant. Sorry for not being clear.
>
> Do you think redisplaying_p would suffice as an indicator?
>
> That should be true if and only if redisplay_internal is in the call stack.
> Also, redisplay_internal is a no-op if called recursively. Or better said,
> both used to be the case.
Yes, I know; and it's still the case. Originally, I indeed only
looked at redisplaying_p. But then cases with C-n and C-v wouldn't be
caught, because these commands, although they call the display code,
run without redisplay_internal in the call stack. And very sluggish
response from these and similar commands is generally perceived as
"redisplay problems". So I wanted to catch them as well, without
waiting for redisplay cycle they cause (which by itself may or may not
be "too slow" -- just moving the cursor is an optimization there, as
you know).
- bug#45898: 27.1; wedged in redisplay again, (continued)
- 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
- bug#45898: 27.1; wedged in redisplay again,
Eli Zaretskii <=
- 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
- bug#45898: 27.1; wedged in redisplay again, Stefan Monnier, 2022/06/29
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/29
- bug#45898: 27.1; wedged in redisplay again, Stefan Monnier, 2022/06/29
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/30
- bug#45898: 27.1; wedged in redisplay again, Stefan Monnier, 2022/06/30
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/30
- bug#45898: 27.1; wedged in redisplay again, Stefan Monnier, 2022/06/30