bug#31920: 26.1; frame appears in wrong part of desktop after restoring frameset from fullscreen

[martin rudalics <rudalics@gmx.at>]

 >> IIUC C-x r f runs the command 'frameset-to-register' which stores a
 >> "framset" in a register.  C-x r j runs the command 'jump-to-register'
 >> which does _not_ restore a frame's state via 'frameset--restore-frame'
 >> but goes to 'set-frame-configuration' instead.  Apparently, framesets
 >> and frame configurations differ in a couple of minor aspects and the
 >> fullscreen state is one of them.
 >
 > They do, but when edebugging jump-to-register, I end up in this branch
 > of the cond:
 >
 >       ((registerv-p val)
 >        (cl-assert (registerv-jump-func val) nil
 >                "Don't know how to jump to register %s"
 >                (single-key-description register))
 >        (funcall (registerv-jump-func val) (registerv-data val)))
 >
 > Which ends up calling frameset--restore-frame, so the problem is elsewhere.

Aha.  I have no idea how to debug these cl-forms so I usually end up
in some sort of nirvana.  On Windows I call WM_EMACS_SETWINDOWPOS (in
my_set_window_pos) with

   x = 902,
   y = 18,
   cx = 0,
   cy = 0,

and Windows gets back to me with a WM_MOVE for (0, 0) - the values
offered by GetWindowRect being

   left = 0,
   top = 0,
   right = 680,
   bottom = 658

I have no idea what to learn from this: (902, 18) is the correct
request and I see no intervening action from there until Windows
returns (0, 0).

 > The code that causes the frame to be restored in the wrong place is
 > this:
 >
 >      (modify-frame-parameters frame
 > 			     (if (eq (frame-parameter frame 'fullscreen) fullscreen)
 > 				 ;; Workaround for bug#14949
 > 				 (assq-delete-all 'fullscreen filtered-cfg)
 > 			       filtered-cfg))
 >
 > in framset--restore-frame, which means Iʼm going to have to break out
 > gdb and/or printf.

And removing the special fullsreen handling doesn't change anything?
Maybe we _should_ do something special when a fullscreen frame is
restored to a non-fullscreen one.

Basically, Emacs has been doing something inherently wrong all the
time: It asks to resize a frame while that frame is in fullscreen (or
maximized) state.  The correct interpretation on behalf of the window
manager would be to store the new sizes and apply them when the frame
is returned to its normal (non-fullscreen/non-maximized) state, IMHO.
For some reason, the approach chosen by Emacs has worked so I never
tried to fiddle with it.  But maybe it bites us this time.

 >(Iʼm surprised Eli is seeing this on MS-Windows
 > though, I thought the low-level frame implementation was completely
 > separate)

I see this on Windows too.  Normally, buggy behavior consistent across
platforms is an asset.  For some reason, this doesn't apply here yet.

martin