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

Previous Next

Full log

View this message in rfc822 format

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

Thanks!

> Am 25.06.2022 um 14:54 schrieb Eli Zaretskii <eliz <at> gnu.org>:
> 
> 
>> 
>> 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.