[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 12:57:55 +0300 |
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Sat, 25 Jun 2022 11:49:42 +0200
> Cc: 45898@debbugs.gnu.org
>
> Well... update_display_code_iteration_ticks also makes me twitch because I
> think of the tick/signal business not part of "display". What I have in my
> head is regexp -> ticks, and iterator -> ticks, where "ticks" would be
> replaced with some suitable name. I think regexp should also be interrupted
> with long lines, when we match a line that is too long. Or not?
>
> Or maybe "ticks" is already a good enough name? We could then simply have
> update_ticks and good. Or eticks to not confuse it with time ticks, if that
> ever happens.
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.
> >> (BTW, the call to update the tick in regexp can lead to a GC when the
> >> error is signaled, in the same way as
> >> in bug 56108 with maybe_quit. So we might need that, too.)
> >
> > Yes, it could cause GC, but I'm not sure what you mean by "we might
> > need that". What is "that" here?
>
> I meant a fix for that bug.
Ah, okay. That will get installed soon, I'm just waiting for Stefan
to comment if he has comments.
> >> /* True while some display-engine code is working on layout of some
> >> window.
> >
> > The reason for that kludge is the urge to avoid signaling an error
> > when regexp or syntax.c is called in the context that is not related
> > to any display code whatsoever. Since these functions don't know
> > whether they are invoked by some code in Iterator or by Lisp, they
> > will count the ticks regardless, and I don't want them to signal an
> > error if they happen to count too many ticks.
>
> 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.
> Apart from features I don't know, I don't see any fundamental problem with
> your approach.
Great, thanks.
- bug#45898: 27.1; wedged in redisplay again, (continued)
- 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
- 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 <=
- 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, 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