From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: 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) Message-ID: References: <> <<83ppe5mfed.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1412613151 20235 80.91.229.3 (6 Oct 2014 16:32:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Oct 2014 16:32:31 +0000 (UTC) Cc: 18637@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 06 18:32:24 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XbBCx-0002XZ-Nq for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Oct 2014 18:32:23 +0200 Original-Received: from localhost ([::1]:53000 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbBCx-0001cK-Cg for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Oct 2014 12:32:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50010) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbBCl-0001YH-Lo for bug-gnu-emacs@gnu.org; Mon, 06 Oct 2014 12:32:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XbBCc-0005Ov-Sn for bug-gnu-emacs@gnu.org; Mon, 06 Oct 2014 12:32:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44384) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbBCc-0005OX-Pk for bug-gnu-emacs@gnu.org; Mon, 06 Oct 2014 12:32:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XbBCc-0007UG-04 for bug-gnu-emacs@gnu.org; Mon, 06 Oct 2014 12:32:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Oct 2014 16:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18637-submit@debbugs.gnu.org id=B18637.141261306928711 (code B ref 18637); Mon, 06 Oct 2014 16:32:01 +0000 Original-Received: (at 18637) by debbugs.gnu.org; 6 Oct 2014 16:31:09 +0000 Original-Received: from localhost ([127.0.0.1]:35948 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbBBj-0007T0-Tm for submit@debbugs.gnu.org; Mon, 06 Oct 2014 12:31:08 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:33865) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbBBh-0007Sr-DF for 18637@debbugs.gnu.org; Mon, 06 Oct 2014 12:31:06 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s96GV3nD007394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Oct 2014 16:31:04 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s96GV2Da010142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Oct 2014 16:31:03 GMT Original-Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s96GV2VF002852; Mon, 6 Oct 2014 16:31:02 GMT In-Reply-To: <<83ppe5mfed.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:94208 Archived-At: > > Is there no support for multiple monitors on MS Windows? >=20 > 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=3Dvs.85%29.aspx > (We don't support the "independent monitors" mode mentioned there.) >=20 > 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 >=20 > 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. >=20 > You can't. >=20 > > 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. >=20 > 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-bound= s'. 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.