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

Previous Next

Full log

Message #158 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 15:54:25 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Sat, 25 Jun 2022 14:20:52 +0200
> Cc: 45898 <at> debbugs.gnu.org
> 
> 
> 
> > 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).
> 
> Do you have a recipe for reproducing that?
> 
> I might take at look into this, if/when I manage to debug Emacs on my M1.

In

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45898#80

Phil Sainty shared URLs for some files that are notoriously slow to
display (and originally were the motivation for developing and
improving the so-long-mode).  Try C-n and C-v with any of them.

This message:

  https://lists.gnu.org/archive/html/help-gnu-emacs/2022-05/msg00070.html

mentions another problematic file.  With it, you need first to arrive
to buffer position 135,000, before C-n/C-v become sluggish.

These are the sample files I used to test the implementation of this
feature.

Previous Next

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