GNU bug report logs - #77039
31.0.50; Flickering on macOS

Previous Next

Package: emacs;

Reported by: Aaron Jensen <aaronjensen <at> gmail.com>

Date: Sat, 15 Mar 2025 16:43:01 UTC

Severity: normal

Found in version 31.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: alan <at> idiocy.org, 77039 <at> debbugs.gnu.org, aaronjensen <at> gmail.com
Subject: bug#77039: 31.0.50; Flickering on macOS
Date: Sat, 22 Mar 2025 22:30:21 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: aaronjensen <at> gmail.com,  alan <at> idiocy.org,  77039 <at> debbugs.gnu.org
> Date: Sat, 22 Mar 2025 21:20:09 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> I'd also look for something doing things to mode-line-format first,
> >> maybe.  But I also have no real idea what that is.
> >
> > Given that the glyph rows in question have their mode_line_p flag
> > reset, is that still a possibility?
> 
> Hm, probably not.
> 
> But could this make a difference?
> 
> 
> dispnew.c:
>  5261 static int
>  5262 scrolling_window (struct window *w, int tab_line_p)

Why would scrolling_window be called at all if we never call
update_window for buffers that are not shown in any window?

AFAIU, the scenario is that the sub-process is inserting text into a
buffer that isn't shown in any window on display.  In this case,
redisplay is supposed to conclude that no window needs to be redrawn,
and if so, update_window will not be called for any window.  Right?
This bug report was last modified 113 days ago.

Previous Next

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