GNU bug report logs - #44180
28.0.50; Emacs frames won't redisplay unless resized

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 44180 <at> debbugs.gnu.org
Subject: bug#44180: 28.0.50; Emacs frames won't redisplay unless resized
Date: Sat, 31 Oct 2020 10:28:03 +0200

> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
> Cc: 44180 <at> debbugs.gnu.org
> Date: Tue, 27 Oct 2020 12:48:52 -0700
> 
> Okay, hope this is helpful. I start in a workspace with only the
> terminal, do the gdb dance, and when I run "r -Q" the first frame
> appears, in stacked mode, taking up the whole screen. I create a second
> frame: now i3 has a vertical stack of three windows: terminal, emacs1
> and emacs2 -- emacs2 is focused.
> 
> I shut off blink cursor and global eldoc, note the frame addresses, then
> move focus "wrap-around" style down and back around to the terminal, so
> the emacs1 window (which is the "stuck" one in master) never receives
> focus (that might not be important).
> 
> Back in the terminal I pause execution, set the expose_frame breakpoint,
> turn on logging, and continue. Then move focus down to emacs1, back up
> to the terminal, see the breakpoint has triggered, get a backtrace, and
> confirm that the frame in question is indeed emacs1.
> 
> I did that exact routine in both master and a "revert" branch, with the
> commit reverted.

The backtraces look identical.  So does this mean expose_frame returns
immediately in the "master" case without doing anything, but in the
"revert" case it doesn't return?  If so, is the reason the fact that
the problematic frame is marked as "garbaged" in the "master" case,
but not in the "revert" case?

Previous Next

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