bug#49959: Diff file (Was: Re: bug#49959: 28.0.50; Emacs got quasi freeze)

[martin rudalics <rudalics@gmx.at>]

 > MR>  Hopefully.  It doesn't break the behavior under xfce/xfwm4.  I yet have
 > MR>  to test with Gnome and Plasma.  Meanwhile please do the following:
 >
 > MR>  Apply the attached patch which adds a few diagnostics.  Then evaluate
 >
 > MR>    (setq frame-size-history '(100))
 >
 > MR>  switch to the other virtual desktop, switch back to the Emacs
 > MR>  desktop, evaluate
 >
 > MR>    (frame--size-history frame)
                               ^^^^^
This was a bug on my side ...

 > MR>    (pop-to-buffer "*frame-size-history*")
 >
 > MR>  and tell me what *frame-size-history* contains now.
 >
 > #<buffer *frame-size-history*>

... so please try again with:

Then evaluate

   (setq frame-size-history '(100))

switch to the other virtual desktop, switch back to the Emacs
desktop, evaluate

   (frame--size-history)
   (pop-to-buffer "*frame-size-history*")

and tell me what *frame-size-history* contains now.

 > MR>  And please also try the following: With emacs -Q put into *scratch*
 > MR>  the lines
 >
 > MR>  (setq frame (make-frame))
 > MR>  (frame-visible-p frame)
 > MR>  (make-frame-invisible frame)
 > MR>  (make-frame-visible frame)
 > MR>  (iconify-frame frame)
 >
 > MR>  Now use C-x C-e after any of these forms to first make FRAME and, for
 > MR>  example, make FRAME invisible, then make it iconified, then make it
 > MR>  visible and so on.  After every step use the `frame-visible-p' form to
 > MR>  check what Emacs thinks FRAME is.

Silly me again: I meant "what Emacs thinks in what state FRAME is"
namely, not visible (nil), iconified (icon), or visible (t).

 > If you find a transition that you
 > MR>  think is not correct, please tell me.
 >
 > The transition is corrext, and FRAME is *scratch*.

I meanwhile got around installing Enlightenment here and note that I
cannot deiconify a frame via

(iconify-frame frame)
(make-frame-visible frame)

The frame stays iconified.  Can you confirm?  I see the same behavior
with GNOME shell - so maybe this is expected and was so ever since.

martin