bug#24119: 25.1; suspend-frame "freezes" Emacs under i3-wm

[Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net>]

Benjamin Riefenstahl writes:
> To speculate, I would guess that Emacs just disables some stuff inside
> iconify-frame, because it expects its request for iconification to be
> honored by the WM.  I will try to trace that further.

iconify-frame calls x_iconify_frame.  This calls in order

  FRAME_DISPLAY_INFO (f)->x_highlight_frame = 0;
  x_set_bitmap_icon (f);
  SET_FRAME_VISIBLE (f, 0);
  SET_FRAME_ICONIFIED (f, true);

I commented these out individually, and the result is that setting
x_highlight_frame causes the cursor to stop blinking and stay hollow and
SET_FRAME_VISIBLE (f,0) causes further keyboard input to be buffered and
not yet executed.  There are three implementations inside this function,
for GTK, for Xt and without any toolkit, but all versions call these
functions.

The GTK documentation says to register for the signal
"window-state-event" to wait for the WM to react.  But Emacs already
handles the underlying relevant X11-Event "UnmappedNotify" and it calls
SET_FRAME_VISIBLE (f, 0) and SET_FRAME_ICONIFIED (f, true) there again.

x_highlight_frame seems to be structured the same as
x_make_frame_visible and x_make_frame_invisible just above it.  I have
not yet investigated where and how those functions are used.

I would suggest to remove the calls to SET_FRAME_VISIBLE and
SET_FRAME_ICONIFIED from x_iconify_frame and to move the setting of
x_highlight_frame to the handling of "UnmappedNotify".  I would do this
for all three implementations of x_iconify_frame.

I just did preliminary tests with the GTK implementation (i.e. USE_GTK)
and with the Mate-WM and it seems to work.  Of course, this would have
to be tested with the other implementations of x_highlight_frame and
with other WMs, at least Gnome 3 and KDE.