GNU bug report logs - #18637
24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows

Previous Next

Full log

Message #23 received at 18637 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 18637 <at> debbugs.gnu.org
Subject: RE: bug#18637: 24.4.50;	doc of frame parameter DISPLAY vs actual
 value on MS Windows
Date: Mon, 6 Oct 2014 09:31:00 -0700 (PDT)

> > Is there no support for multiple monitors on MS Windows?
> 
> There is, but by and large, Emacs will see them as a single large
> desktop.  See here:
> http://msdn.microsoft.com/en-us/library/dd145071%28v=vs.85%29.aspx
> (We don't support the "independent monitors" mode mentioned there.)
> 
> In any case, "multiple monitors" and "multiple displays" are 2
> different issues.  Each display can have multiple monitors.

OK.  Where can one find doc about using multiple monitors with Emacs?

> > I was not able to find out how to obtain info about which monitor
> > is being used to show a particular frame
> 
> The functions you mentioned provide that info, or maybe I don't
> understand what info are you looking for.q

Which function tells you what monitor is showing a given frame (on
MS Windows)?

I should maybe point out that the OP reporting this problem is not on
MS Windows, AFAIK.  My question about Windows was for me, to see if I
could understand the problem even though I am on Windows (and even
though I do not have multiple monitors).

> > how to specify which monitor to use to display a particular frame.
> 
> You can't.
> 
> > The symptom reported was that by modifying a frame's parameters
> > to restore its previous values of `top', `left', `width' and
> > `height', the frame got moved to another monitor, for some
> > reason.
> 
> Probably because the pixel coordinates mapped to that other monitor,
> the URL above explains that, among other things.

I appreciate your replies and your trying to help, but I don't quite
understand you here.  The URL you cite introduces a long chapter.

My Lisp code in question simply does this:

1. If not "maximized" then "maximize", after recording the original
   frame location and size, by setting frame parameters `restore-left',...
   `restore-height' to the original values of parameters `left',...`height'.

2. If "maximized" then use `modify-frame-parameters' to restore
   parameters `left',...`height' to the values saved in parameters
   `restore-left',...`restore-height'.

I put "maximized" in quotes here because the code maximizes not wrt
the screen but the screen possibly minus the space used by a standalone
minibuffer frame.  But that should be an irrelevant detail.

No doubt the problematic code is somewhere in my function
`maximize-frame', which calculates the position and size for maximizing.
It uses either function `mac-display-available-pixel-bounds', if
available, or functions `x-display-pixel-width' and
`x-display-pixel-height'.

I'm guessing that that is the problem (?) - I do not pass the frame as
an argument to `x-display-pixel-*'.  But the doc for those functions
says (since Emacs 20, and still now) that if arg DISPLAY is omitted
then the display of the selected frame is used.  So I would think
that it would not be necessary to pass the selected frame as arg.

You say that a monitor is not a display - OK.  But I do not see
anything that speaks to which monitor gets used.  I am only using
the available display space, as returned by `x-display-pixel-*'.

Dunno what else the problem could be here - i.e., why the newly
repositioned and resized frame would show up on the other monitor.
All the other functions I call here pass the frame explicitly.

In sum, all the code does is either (b) "maximize", by repositioning
and resizing to fit (essentially) what `x-display-pixel-width' and
`x-display-pixel-height' say is the available space or (b) reposition
and resize back to previous `left' etc. settings.  Why the frame ends
up being moved to another monitor is a mystery to me.

This is the full function definition:

(defun frcmds-available-screen-pixel-bounds ()
  "Returns a value of the same form as option `available-screen-pixel-bounds'.
This represents the currently available screen area."
  (or available-screen-pixel-bounds     ; Use the option, if available.
      (if (fboundp 'mac-display-available-pixel-bounds) ; Mac-OS.
          (mac-display-available-pixel-bounds)
        (list 0
              0
              (x-display-pixel-width)
              (x-display-pixel-height)))))

You say "Probably because the pixel coordinates mapped to that other
monitor", and that the URL explains this.  Could you elaborate, or point
me to the section of that chapter that you have in mind?  Do you think
there is something I am not doing that I should be doing, to try to keep
the calculation of the display size to the current monitor?

I understand that on MS Windows the surface of the available monitors
is summed to give the display size.  But (a) I don't think the OP is on
Windows and (b) I don't see how that would be a problem anyway.  It seems
to be (I'm guessing) that the `left' setting is somehow giving a
coordinate that corresponds to, or is being interpreted as, a coordinate
on the other monitor.

Yes, this is verbose, and no, I don't expect that you have the answer to
my coding problem.  If you do have some light to shine on this, however,
then that is appreciated.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.