bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows

[Eli Zaretskii]

> Date: Tue, 7 Oct 2014 11:12:56 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 18637@debbugs.gnu.org
> 
> > That's my understanding as well, but someone who has access to such
> > a system should actually try that and report back.
> > 
> > > I guess that would mean that frame-position coordinates (`left',
> > > `top') are then interpreted relative to that other monitor (?).
> > > Is that right?
> > 
> > No, I think they are "ignored".  That is, the coordinates are
> > interpreted in the virtual coordinate system, but then Windows
> > decides on its own how to position the frame, using the criterion
> > described above.
> 
> By "criterion described above, do you mean just based on which monitor
> is showing more of the frame?

Yes.

> (Note too that I am using MS Windows, but the OP who reported the
> problem is, I think, not on Windows.)

Then the problem might be even more complicated than I thought ;-)

> > > But if that were the case then I would think that restoring a
> > > recorded `left' etc. parameter later would put the frame back
> > > where it was, which is apparently not what is happening.
> > 
> > Except that Windows has its own rules, see above, at least when you
> > create a frame that didn't exist (i.e. restore it from information
> > recorded in some file).
> 
> This code does not create any new frames.  It just calls
> `modify-frame-parameters' on an existing frame, setting its `left',
> `top', `width', and `height' parameters.

Then I'd expect it to "just work".  Of course, it doesn't, so there's
some factor or factors at work that we don't understand.

> > That's a lot of code, and I have no way of trying it.
> 
> If you are interested, you can try it easily, by downloading these
> two files:
> http://www.emacswiki.org/emacs-en/download/frame-cmds.el
> http://www.emacswiki.org/emacs-en/download/frame-fns.el

No, I meant I have no access to a system with more than one monitor.