GNU bug report logs - #59038
loading this base64 file makes emacs -Q 28.2 peg a core infinitely

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: luangruo <at> yahoo.com, gerd.moellmann <at> gmail.com, 59038 <at> debbugs.gnu.org, checker <at> d6.com
Subject: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a core infinitely
Date: Sun, 06 Nov 2022 08:00:00 +0200

> Date: Sat, 5 Nov 2022 22:03:51 +0000
> Cc: Chris Hecker <checker <at> d6.com>,
>   Gerd Möllmann <gerd.moellmann <at> gmail.com>,
>   59038 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > All of this is no longer a problem in Emacs 29, and even if you somehow
> > still cause redisplay to become wedged, you can set max-redisplay-ticks
> > to a suitable value.
> 
> I looked that up in Emacs with C-h v.  It says it's the maximum number
> of "redisplay ticks" before some aborting or other occurs.
> 
> I don't know what a redisplay tick is, and the dock string doesn't
> explain it.  I've never heard of the term before.
> 
> This doc string is thus not very helpful, quite the reverse.
> 
> Maybe one of the manuals explains it.  It would be nice to have that
> doc string amended to be less puzzling.

There's nothing to explain that can be easily explained to someone who
isn't privy to the display code internals.  What does "redisplay
ticks" tell you intuitively?  Chances are your intuition is correct.

The mechanisms behind that variable are not important, as long as our
recent measures to cope with very long lines do their job, so I see no
reason to document the ticks stuff more than it already is.  If you
are really interested, grep the sources for update_redisplay_ticks.

Previous Next

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