bug#26537: Problems with Emacs frame (GTK)

[martin rudalics <rudalics@gmx.at>]

 >> Just a simple step: Does setting the variable `x-gtk-use-window-move' to
 >> nil change anything in your scenario?  I doubt it will but who knows.
 >
 > Yes, it changes the scenario. That setting seems to fix, at least
 > partially, the issue. "partially" because sometimes Emacs starts with
 > the wrong widths for text and speedbar window, but just restarting it
 > works.

That's bad because you sooner or later might run into troubles with
GTK+.

 > Regarding "screen-no-desktop.png" I get it with the init.el file I had
 > attached with *all* builds, only that for those <= 20170327 saving the
 > desktop fixed the issue regarding the speedbar width
 > ("screen-with-desktop-OK.png")

But relying on desktop saving to fix an issue is not the recommended
way.

 > If you still want the results you have requested, I will try..

Why "try"?  There's no black magic involved.

(1) Start Emacs with your init file only.  After that type

     M-: (window--dump-frame)

     This will create a buffer called *window-frame-dump*.  Put the
     contents of that buffer into your mail body marking them with
     "screen-no-desktop".  Exit Emacs saving the desktop.

(2) Start some pre March 27 build with the saved desktop and proceed as
     above but mark the contents with "screen-with-desktop-OK".

(3) Start current master with `x-gtk-use-window-move' t and the saved
     desktop and proceed as above but mark the contents with
     "screen-with-desktop-NOT_OK".

Then we should have enough information to tell what really goes on.

Obviously, if, without desktop restoring, the current master produces an
initial frame different from those of the earlier builds, I would want
to see the results for that one too.  But you said that they are equal.

Thanks, martin