GNU bug report logs - #45898
27.1; wedged in redisplay again

Previous Next

Package: emacs;

Reported by: Devon Sean McCullough <Emacs-hacker2018 <at> jovi.net>

Date: Fri, 15 Jan 2021 18:14:01 UTC

Severity: normal

Found in version 27.1

Full log


Message #140 received at 45898 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 45898 <at> debbugs.gnu.org
Subject: Re: bug#45898: 27.1; wedged in redisplay again
Date: Sat, 25 Jun 2022 12:57:55 +0300
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Sat, 25 Jun 2022 11:49:42 +0200
> Cc: 45898 <at> 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.




This bug report was last modified 2 years and 357 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.