On 10/27/20 10:08 AM, martin rudalics wrote:
>>> Do you get the corresponding focus events (whatever they are now) when
>>> you make another frame the fullscreen one?  If so, we should probably
>>> redraw the frame in that case.
>>
>> I'm still not at the offending computer, but I think there's a high
>> likelihood of confusing myself with conflicting terminology here so,
>> just to be clear: this isn't proper fullscreening in the X11 sense.
>
> I didn't expect it to be but thanks for confirming.
>
>> i3
>> also does that, but I hardly ever use it since the stacked layout is
>> close enough to full screen. In X11 terms I think all that's happening
>> is switching of focus between windows, it's just that i3's layout means
>> that the unfocused windows are always completely obscured. For some
>> reason Emacs now thinks that a window being obscured means that it's now
>> an icon. Switching focus back to that window does not un-iconify it.
>
> Always keep in mind that Emacs has no idea about whether and how a
> window has been iconified or focused.  It just waits for the
> corresponding information from the window manager, believes what the
> latter tells and acts (redrawing a frame, for example) accordingly.

Okay, thanks.

I think I'm going to need more help here, though. I have built master
with optimizations off, I start GDB in a controlling emacs, set a
breakpoint at xdisp.c:34381 at the beginning of expose_frame, and then
"run -Q".

That pops up a new frame, and we hit the breakpoint. I run "bt" and have
attached the resulting backtrace. Something tells me you need more
information than this, though. I went up a frame, to handle_one_xevent,
where there are a bunch of local values I can print, but the values of
dpyinfo and event are enormous structures.

What variables exactly would you need to see?

Again, this is on misbehaving master. Once I know exactly what you need
I'll do the same for a build with the commit reverted.

Thanks,
Eric