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

Previous Next

Full log

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 45898 <at> debbugs.gnu.org
Subject: Re: bug#45898: 27.1; wedged in redisplay again
Date: Sat, 25 Jun 2022 13:10:14 +0200

> On 2022-06-25,, at 11:57 , Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Date: Sat, 25 Jun 2022 11:49:42 +0200
>> Cc: 45898 <at> debbugs.gnu.org
>> 
>> 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.

I love update_ticks!  And I'm good with names, trust me ;-).  And I'm volunteering to do the work!

>> 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.

Previous Next

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