bug#25851: 25.2; GTK warning when starting Emacs when desktop file has more than one frame

[nljlistbox2@gmail.com (N. Jackson)]

Hello Martin,

At 15:24 +0100 on Friday 2017-03-03, martin rudalics wrote:

> One thing that doesn't work are negative offsets like in emacs
> -Q -g 80x40-20-20.

Here I can successfully position frames partially off the display
(using the mouse) but when they are restored from a desktop file,
they are moved slightly so that are fully on the display. (Perhaps
this is what you mean?) I don't see that this is necessarily bad
behaviour. (Others might (probably will!) disagree of course...)

> If you don't mind, continue using it for a while; maybe you
> detect something strange.

Yes, I am using (and I will continue to use) your proposed
definition of `xg_set_geometry' from Message #122
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25851#122).

I will keep my eye out for any oddities. So far, so good.
(Although, I should note that my usage of frames is very
tame/conservative; I tend to keep the same configuration of three
(sometimes four) full screen frames at all times.)

>> [1] As has been happening for a while, buffers seem to be
>> assigned randomly (it seems) to the windows restored from the
>> desktop file
>
> It would be nice if you were able to bisect that "while". The
> idea is obviously that windows come up with their original
> buffers restored.

I considered reporting this bug a few months ago, but I couldn't
make enough sense of the behaviour I was seeing to write a
coherent report.

I tried again today, and I can no longer reproduce the problem!
Yet I saw it as recently as last week while I was preparing the
bug report for the current bug (bug#25851). Perhaps deleting old
desktop files has made the problem go away? I don't know.

But yes, if I start seeing the problem again, and if I have a
desktop file that I can use for testing, I will try to bisect
revisions to see when the behaviour was introduced.

Regards,
N.