From unknown Mon Aug 18 04:45:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Oct 2014 19:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 18637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 18637@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.141253705021750 (code B ref -1); Sun, 05 Oct 2014 19:25:01 +0000 Received: (at submit) by debbugs.gnu.org; 5 Oct 2014 19:24:10 +0000 Received: from localhost ([127.0.0.1]:34915 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XarPd-0005ej-P1 for submit@debbugs.gnu.org; Sun, 05 Oct 2014 15:24:10 -0400 Received: from eggs.gnu.org ([208.118.235.92]:44567) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XarPb-0005eb-FY for submit@debbugs.gnu.org; Sun, 05 Oct 2014 15:24:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XarPQ-0001BT-Uq for submit@debbugs.gnu.org; Sun, 05 Oct 2014 15:24:07 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:59220) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XarPQ-0001BP-Rd for submit@debbugs.gnu.org; Sun, 05 Oct 2014 15:23:56 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46273) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XarPI-0005uX-42 for bug-gnu-emacs@gnu.org; Sun, 05 Oct 2014 15:23:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XarP9-00016V-C8 for bug-gnu-emacs@gnu.org; Sun, 05 Oct 2014 15:23:48 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:47686) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XarP9-00016F-44 for bug-gnu-emacs@gnu.org; Sun, 05 Oct 2014 15:23:39 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s95JNb4J018281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 5 Oct 2014 19:23:38 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s95JNaRX010190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 5 Oct 2014 19:23:37 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s95JNa3R010187 for ; Sun, 5 Oct 2014 19:23:36 GMT MIME-Version: 1.0 Message-ID: <12fc196e-cc82-4f22-8d2f-cede95542ea7@default> Date: Sun, 5 Oct 2014 12:23:34 -0700 (PDT) From: Drew Adams X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) In (elisp) `Basic Parameters' I see this description of frame parameter `display': The display on which to open this frame. It should be a string of the form `"HOST:DPY.SCREEN"', just like the `DISPLAY' environment variable. But if I evaluate `(frame-parameters)' on MS Windows I see this value for parameter `display': "w32". "w32" does not seem to fit the form `"HOST:DPY.SCREEN"'. What gives? And why is that string surrounded by `...'? And why aren't the components of that "form" described: What are acceptable values for HOST, DPY, and SCREEN? (I assume that the `:' and `.' are to be taken literally here, and that HOST, DPY, and SCREEN are placeholders, although there is zero explanation of this.) Also, I searched the manual case-sensitively for DISPLAY, and found no desc= ription/specification/explanation of "the `DISPLAY' environment variable. = So referring users to that env var to find a specification of the form `"HOST:DPY.SCREEN"' is unhelpful and misleading. Please clear up this doc - make it properly specify what form the value of parameter `display' takes. In GNU Emacs 24.4.50.1 (i686-pc-mingw32) of 2014-09-15 on LEG570 Bzr revision: 117884 dancol@dancol.org-20140915050944-sqsajysnwef51f9m Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --enable-checking 'CFLAGS=3D-O0 -g3' CPPFLAGS=3D-DGLYPH_DEBUG= =3D1' From unknown Mon Aug 18 04:45:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Oct 2014 19:31: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: To: Drew Adams Cc: 18637@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 18637-submit@debbugs.gnu.org id=B18637.141253742122402 (code B ref 18637); Sun, 05 Oct 2014 19:31:01 +0000 Received: (at 18637) by debbugs.gnu.org; 5 Oct 2014 19:30:21 +0000 Received: from localhost ([127.0.0.1]:34924 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XarVc-0005pF-Mr for submit@debbugs.gnu.org; Sun, 05 Oct 2014 15:30:21 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:38711) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XarVZ-0005p6-SQ for 18637@debbugs.gnu.org; Sun, 05 Oct 2014 15:30:18 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NCZ00H00KC6PV00@a-mtaout23.012.net.il> for 18637@debbugs.gnu.org; Sun, 05 Oct 2014 22:30:16 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NCZ00HOEKUFQ900@a-mtaout23.012.net.il>; Sun, 05 Oct 2014 22:30:16 +0300 (IDT) Date: Sun, 05 Oct 2014 22:30:22 +0300 From: Eli Zaretskii In-reply-to: <12fc196e-cc82-4f22-8d2f-cede95542ea7@default> X-012-Sender: halo1@inter.net.il Message-id: <83vbnymi0h.fsf@gnu.org> References: <12fc196e-cc82-4f22-8d2f-cede95542ea7@default> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 5 Oct 2014 12:23:34 -0700 (PDT) > From: Drew Adams > > In (elisp) `Basic Parameters' I see this description of frame parameter > `display': > > The display on which to open this frame. It should be a string of > the form `"HOST:DPY.SCREEN"', just like the `DISPLAY' environment > variable. > > But if I evaluate `(frame-parameters)' on MS Windows I see this value > for parameter `display': "w32". > > "w32" does not seem to fit the form `"HOST:DPY.SCREEN"'. What gives? Emacs on MS-Windows doesn't support the notion of 'display', so all frames return the same value of that parameter. > And why is that string surrounded by `...'? An artifact of Texinfo markup. > And why aren't the components of that "form" described: What are > acceptable values for HOST, DPY, and SCREEN? Users on X already know what they are; users on other systems don't need to know, because this is not supported. Either way, this notion is not an Emacs invention, it is a feature of the X window system. From unknown Mon Aug 18 04:45:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Oct 2014 19:45: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: To: drew.adams@oracle.com Cc: 18637@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 18637-submit@debbugs.gnu.org id=B18637.141253824923633 (code B ref 18637); Sun, 05 Oct 2014 19:45:01 +0000 Received: (at 18637) by debbugs.gnu.org; 5 Oct 2014 19:44:09 +0000 Received: from localhost ([127.0.0.1]:34928 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xariy-000697-I1 for submit@debbugs.gnu.org; Sun, 05 Oct 2014 15:44:08 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:47759) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xariw-00068y-Kt for 18637@debbugs.gnu.org; Sun, 05 Oct 2014 15:44:07 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NCZ00N00KV8RD00@mtaout26.012.net.il> for 18637@debbugs.gnu.org; Sun, 05 Oct 2014 22:42:15 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NCZ00LHMLEFAL40@mtaout26.012.net.il>; Sun, 05 Oct 2014 22:42:15 +0300 (IDT) Date: Sun, 05 Oct 2014 22:44:11 +0300 From: Eli Zaretskii In-reply-to: <83vbnymi0h.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83tx3imhdg.fsf@gnu.org> References: <12fc196e-cc82-4f22-8d2f-cede95542ea7@default> <83vbnymi0h.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 05 Oct 2014 22:30:22 +0300 > From: Eli Zaretskii > Cc: 18637@debbugs.gnu.org > > > Date: Sun, 5 Oct 2014 12:23:34 -0700 (PDT) > > From: Drew Adams > > > > In (elisp) `Basic Parameters' I see this description of frame parameter > > `display': > > > > The display on which to open this frame. It should be a string of > > the form `"HOST:DPY.SCREEN"', just like the `DISPLAY' environment > > variable. Btw, this is not the best place in the manual to read about this. A better one is "Multiple Terminals", where it says explicitly that this is only relevant on X. The index entry "displays, multiple" leads to that node. From unknown Mon Aug 18 04:45:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Oct 2014 02:56:02 +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: To: Eli Zaretskii , drew.adams@oracle.com Cc: 18637@debbugs.gnu.org Received: via spool by 18637-submit@debbugs.gnu.org id=B18637.141256415711805 (code B ref 18637); Mon, 06 Oct 2014 02:56:02 +0000 Received: (at 18637) by debbugs.gnu.org; 6 Oct 2014 02:55:57 +0000 Received: from localhost ([127.0.0.1]:35134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XaySq-00034K-JD for submit@debbugs.gnu.org; Sun, 05 Oct 2014 22:55:57 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:27751) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XaySo-00034C-Gu for 18637@debbugs.gnu.org; Sun, 05 Oct 2014 22:55:55 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s962tqNG009608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Oct 2014 02:55:53 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s962tpH4009532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Oct 2014 02:55:52 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s962tpgS009523; Mon, 6 Oct 2014 02:55:51 GMT MIME-Version: 1.0 Message-ID: Date: Sun, 5 Oct 2014 19:55:48 -0700 (PDT) From: Drew Adams References: <<12fc196e-cc82-4f22-8d2f-cede95542ea7@default>> <<83vbnymi0h.fsf@gnu.org>> <<83tx3imhdg.fsf@gnu.org>> In-Reply-To: <<83tx3imhdg.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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > > > In (elisp) `Basic Parameters' I see this description of frame > > > parameter `display': > > > > > > The display on which to open this frame. It should be a > > > string of the form `"HOST:DPY.SCREEN"', just like the > > > `DISPLAY' environment variable. >=20 > Btw, this is not the best place in the manual to read about this. > A better one is "Multiple Terminals", where it says explicitly > that this is only relevant on X. The index entry "displays, > multiple" leads to that node. As a matter of fact, that is the node I started with, when trying to find out about such things. Please see this help-gnu-emacs thread, where I mention that node and provide some context. http://lists.gnu.org/archive/html/help-gnu-emacs/2014-10/msg00099.html Is there no support for multiple monitors on MS Windows? That's really what I was looking for info about, along with general info about Emacs display on multiple monitors. When looking, I came across the doc for `display-monitor-attributes-list' and `frame-monitor-attributes'. I was not able to find out how to obtain info about which monitor is being used to show a particular frame, or how to specify which monitor to use to display a particular frame. 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. I don't have multiple monitors, to try things out, but I was looking for some info in the manual that might explain what the OP reports. From unknown Mon Aug 18 04:45:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Oct 2014 02:56:02 +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: To: Eli Zaretskii , Drew Adams Cc: 18637@debbugs.gnu.org Received: via spool by 18637-submit@debbugs.gnu.org id=B18637.141256416111821 (code B ref 18637); Mon, 06 Oct 2014 02:56:02 +0000 Received: (at 18637) by debbugs.gnu.org; 6 Oct 2014 02:56:01 +0000 Received: from localhost ([127.0.0.1]:35137 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XaySu-00034a-7R for submit@debbugs.gnu.org; Sun, 05 Oct 2014 22:56:00 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:27760) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XaySs-00034S-Aw for 18637@debbugs.gnu.org; Sun, 05 Oct 2014 22:55:58 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s962tu4V009637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Oct 2014 02:55:57 GMT 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 s962tt0r009640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Oct 2014 02:55:56 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s962ttQE022359; Mon, 6 Oct 2014 02:55:55 GMT MIME-Version: 1.0 Message-ID: Date: Sun, 5 Oct 2014 19:55:52 -0700 (PDT) From: Drew Adams References: <<12fc196e-cc82-4f22-8d2f-cede95542ea7@default>> <<83vbnymi0h.fsf@gnu.org>> In-Reply-To: <<83vbnymi0h.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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > > In (elisp) `Basic Parameters' I see this description of frame > > parameter `display': > > > > The display on which to open this frame. It should be a string > > of the form `"HOST:DPY.SCREEN"', just like the `DISPLAY' > > environment variable. > > > > But if I evaluate `(frame-parameters)' on MS Windows I see this > > value for parameter `display': "w32". > > > > "w32" does not seem to fit the form `"HOST:DPY.SCREEN"'. What > > gives? >=20 > Emacs on MS-Windows doesn't support the notion of 'display', so all > frames return the same value of that parameter. OK, then the doc should mention this, or at least say that the string might not take the form "HOST:DPY.SCREEN" on some platforms, and preferably say something about what to expect on the exceptional platforms (and perhaps give some idea of what use the exceptional value is - what it can be used for, or what info it conveys). > > And why is that string surrounded by `...'? >=20 > An artifact of Texinfo markup. I see. Is that then correct, or should the `...' be absent? There are strings in the manual that are not surrounded by `...'. > > And why aren't the components of that "form" described: What are > > acceptable values for HOST, DPY, and SCREEN? >=20 > Users on X already know what they are; users on other systems don't > need to know, because this is not supported. Either way, this > notion is not an Emacs invention, it is a feature of the X > window system. Then please say that. E.g., say that the value is useful only for X Window, or only relevant for it. If the function itself has no use beyond X Window, then please make that clear. From unknown Mon Aug 18 04:45:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Oct 2014 14:40:02 +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: To: Drew Adams Cc: 18637@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 18637-submit@debbugs.gnu.org id=B18637.141260634717846 (code B ref 18637); Mon, 06 Oct 2014 14:40:02 +0000 Received: (at 18637) by debbugs.gnu.org; 6 Oct 2014 14:39:07 +0000 Received: from localhost ([127.0.0.1]:35890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xb9RK-0004dl-1J for submit@debbugs.gnu.org; Mon, 06 Oct 2014 10:39:06 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:58981) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xb9RE-0004dH-Rx for 18637@debbugs.gnu.org; Mon, 06 Oct 2014 10:39:02 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0ND100L001Z53X00@a-mtaout23.012.net.il> for 18637@debbugs.gnu.org; Mon, 06 Oct 2014 17:38:58 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0ND100LRG20Y2O10@a-mtaout23.012.net.il>; Mon, 06 Oct 2014 17:38:58 +0300 (IDT) Date: Mon, 06 Oct 2014 17:39:06 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83ppe5mfed.fsf@gnu.org> References: X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Sun, 5 Oct 2014 19:55:48 -0700 (PDT) > From: Drew Adams > Cc: 18637@debbugs.gnu.org > > 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: [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.3 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) [URIs: oracle.com] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.175 listed in list.dnswl.org] 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Sun, 5 Oct 2014 19:55:48 -0700 (PDT) > From: Drew Adams > Cc: 18637@debbugs.gnu.org > > 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: [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.175 listed in list.dnswl.org] 0.3 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) [URIs: oracle.com] 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) > Date: Sun, 5 Oct 2014 19:55:48 -0700 (PDT) > From: Drew Adams > Cc: 18637@debbugs.gnu.org > > 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. > 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 > 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. From unknown Mon Aug 18 04:45:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows 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: To: Eli Zaretskii Cc: 18637@debbugs.gnu.org Received: via spool by 18637-submit@debbugs.gnu.org id=B18637.141261306928711 (code B ref 18637); Mon, 06 Oct 2014 16:32:01 +0000 Received: (at 18637) by debbugs.gnu.org; 6 Oct 2014 16:31:09 +0000 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 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 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 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 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 MIME-Version: 1.0 Message-ID: Date: Mon, 6 Oct 2014 09:31:00 -0700 (PDT) From: Drew Adams References: <> <<83ppe5mfed.fsf@gnu.org>> 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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > > 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. From unknown Mon Aug 18 04:45:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Oct 2014 16:35:02 +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: To: Eli Zaretskii Cc: 18637@debbugs.gnu.org, Drew Adams Received: via spool by 18637-submit@debbugs.gnu.org id=B18637.141261329329056 (code B ref 18637); Mon, 06 Oct 2014 16:35:02 +0000 Received: (at 18637) by debbugs.gnu.org; 6 Oct 2014 16:34:53 +0000 Received: from localhost ([127.0.0.1]:35955 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbBFM-0007Ya-Uz for submit@debbugs.gnu.org; Mon, 06 Oct 2014 12:34:53 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:58945) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbBFL-0007YS-0b for 18637@debbugs.gnu.org; Mon, 06 Oct 2014 12:34:51 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYGAIDvNVNFxKjo/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCzQSFBgNJIgECNIZF456B4Q4BKkZgWqBcYFbIQ X-IPAS-Result: ArYGAIDvNVNFxKjo/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCzQSFBgNJIgECNIZF456B4Q4BKkZgWqBcYFbIQ X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="91801960" Received: from 69-196-168-232.dsl.teksavvy.com (HELO pastel.home) ([69.196.168.232]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Oct 2014 12:34:50 -0400 Received: by pastel.home (Postfix, from userid 20848) id 1B0E885CC; Mon, 6 Oct 2014 12:34:50 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83ppe5mfed.fsf@gnu.org> Date: Mon, 06 Oct 2014 12:34:50 -0400 In-Reply-To: <83ppe5mfed.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 06 Oct 2014 17:39:06 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > Each display can have multiple monitors. Indeed, and for that reason, Emacs sees a single large desktop under X11 as well. Stefan From unknown Mon Aug 18 04:45:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Oct 2014 16:55:02 +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: To: Drew Adams Cc: 18637@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 18637-submit@debbugs.gnu.org id=B18637.141261444630992 (code B ref 18637); Mon, 06 Oct 2014 16:55:02 +0000 Received: (at 18637) by debbugs.gnu.org; 6 Oct 2014 16:54:06 +0000 Received: from localhost ([127.0.0.1]:35960 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbBXw-00083n-TS for submit@debbugs.gnu.org; Mon, 06 Oct 2014 12:54:05 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:39276) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbBXt-00083K-9U for 18637@debbugs.gnu.org; Mon, 06 Oct 2014 12:54:02 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0ND100C007XLM700@a-mtaout22.012.net.il> for 18637@debbugs.gnu.org; Mon, 06 Oct 2014 19:53:59 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0ND100CSH89YM310@a-mtaout22.012.net.il>; Mon, 06 Oct 2014 19:53:59 +0300 (IDT) Date: Mon, 06 Oct 2014 19:54:07 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <837g0dm95c.fsf@gnu.org> References: X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Mon, 6 Oct 2014 09:31:00 -0700 (PDT) > From: Drew Adams > Cc: 18637@debbugs.gnu.org > > > > 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? There's nothing to document: they are treated as just one large monitor. The only functions we have are in that node you mentioned. > > > 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)? frame-monitor-attributes, if I understand what you want. > > > 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. Read it and its sections. You will find the information you want there. Skip whatever sounds not relevant or too low-level, and keep reading. > 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. Read the MSDN documentation I pointed to, the answers are there. If, after that, you still don't understand what could go wrong with your code, come back and ask more specific questions with specific code snippets. Right now, what you write and ask just shows how much of the background you are missing to start reasoning about this. The issues are not complicated once you understand how Windows treats multiple monitors. From unknown Mon Aug 18 04:45:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Oct 2014 17:26:02 +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: To: Eli Zaretskii Cc: 18637@debbugs.gnu.org Received: via spool by 18637-submit@debbugs.gnu.org id=B18637.14126163421570 (code B ref 18637); Mon, 06 Oct 2014 17:26:02 +0000 Received: (at 18637) by debbugs.gnu.org; 6 Oct 2014 17:25:42 +0000 Received: from localhost ([127.0.0.1]:35970 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbC2W-0000PC-Mm for submit@debbugs.gnu.org; Mon, 06 Oct 2014 13:25:41 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:23345) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbC2S-0000Ox-EG for 18637@debbugs.gnu.org; Mon, 06 Oct 2014 13:25:37 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s96HPXKZ009979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Oct 2014 17:25:34 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s96HPWZZ005007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Oct 2014 17:25:33 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s96HPWgO013811; Mon, 6 Oct 2014 17:25:32 GMT MIME-Version: 1.0 Message-ID: Date: Mon, 6 Oct 2014 10:25:31 -0700 (PDT) From: Drew Adams References: <> <<837g0dm95c.fsf@gnu.org>> In-Reply-To: <<837g0dm95c.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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > > > 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? >=20 > There's nothing to document: they are treated as just one large > monitor. The only functions we have are in that node you mentioned. > > > > > 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)? >=20 > frame-monitor-attributes, if I understand what you want. I see that that function returns some information about (attributes of) the monitor that is most associated with the argument frame. And I see that one of the attributes is `name'. Presumably, monitors would be distinguished by this parameter. However, it is an optional parameter, so I can't imagine that one can count on it to distinguish monitors. (Just why is it optional?) If one cannot count on `name', how is the identity of monitors determined? Do you just go by the particular cons of attributes that is returned by `frame-monitor-attributes'? Also, FWIW, I don't see, in the doc, where the meanings of those attributes are specified. The doc for `display-monitor-attributes' supposedly does that, but it says nothing about what the "Position", for `geometry' and `workarea', is relative to. And it says nothing about what those attributes mean. I can guess the meaning for `geometry' here, being somewhat familiar with X window `geometry' specs, but there should be some mention or xref to the meaning/use of `geometry' outside Emacs, or else this parameter is unspecified in terms of its meaning or effect. And I cannot guess at all for `workarea'. What is it? How does/can it differ from `geometry'? > > > > 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. >=20 > Read it and its sections. You will find the information you want > there. Skip whatever sounds not relevant or too low-level, and keep > reading. Read the MSDN documentation I pointed to, the answers are there. >=20 > If, after that, you still don't understand what could go wrong with > your code, come back and ask more specific questions with specific > code snippets. Right now, what you write and ask just shows how > much of the background you are missing to start reasoning about this. >=20 > The issues are not complicated once you understand how Windows > treats multiple monitors. OK. From unknown Mon Aug 18 04:45:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows In-Reply-To: <12fc196e-cc82-4f22-8d2f-cede95542ea7@default> Resent-From: Andy Moreton Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Oct 2014 18:10: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: To: 18637@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.14126189665844 (code B ref -1); Mon, 06 Oct 2014 18:10:01 +0000 Received: (at submit) by debbugs.gnu.org; 6 Oct 2014 18:09:26 +0000 Received: from localhost ([127.0.0.1]:35985 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbCir-0001WC-LY for submit@debbugs.gnu.org; Mon, 06 Oct 2014 14:09:25 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41310) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbCio-0001W0-GH for submit@debbugs.gnu.org; Mon, 06 Oct 2014 14:09:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XbCie-0007Ik-Ej for submit@debbugs.gnu.org; Mon, 06 Oct 2014 14:09:22 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:54933) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbCie-0007Ib-B2 for submit@debbugs.gnu.org; Mon, 06 Oct 2014 14:09:12 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbCiW-0003UR-J2 for bug-gnu-emacs@gnu.org; Mon, 06 Oct 2014 14:09:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XbCiP-0007DT-39 for bug-gnu-emacs@gnu.org; Mon, 06 Oct 2014 14:09:04 -0400 Received: from plane.gmane.org ([80.91.229.3]:43928) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbCiO-0007Cz-Sz for bug-gnu-emacs@gnu.org; Mon, 06 Oct 2014 14:08:57 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XbCiK-0005Fs-Hm for bug-gnu-emacs@gnu.org; Mon, 06 Oct 2014 20:08:52 +0200 Received: from uk.solarflare.com ([193.34.186.16]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Oct 2014 20:08:52 +0200 Received: from andrewjmoreton by uk.solarflare.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Oct 2014 20:08:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ From: Andy Moreton Date: Mon, 06 Oct 2014 19:08:38 +0100 Lines: 65 Message-ID: References: > <837g0dm95c.fsf@gnu.org>> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: uk.solarflare.com User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.94 (windows-nt) Cancel-Lock: sha1:emEzRcUV9pGkNo5mrL1Isu9U1xw= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.1 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.1 (----) On Mon 06 Oct 2014, Drew Adams wrote: >> frame-monitor-attributes, if I understand what you want. > > I see that that function returns some information about (attributes > of) the monitor that is most associated with the argument frame. And > I see that one of the attributes is `name'. Presumably, monitors > would be distinguished by this parameter. > > However, it is an optional parameter, so I can't imagine that one can > count on it to distinguish monitors. (Just why is it optional?) > If one cannot count on `name', how is the identity of monitors > determined? Do you just go by the particular cons of attributes > that is returned by `frame-monitor-attributes'? > > Also, FWIW, I don't see, in the doc, where the meanings of those > attributes are specified. The doc for `display-monitor-attributes' > supposedly does that, but it says nothing about what the "Position", > for `geometry' and `workarea', is relative to. And it says nothing > about what those attributes mean. > > I can guess the meaning for `geometry' here, being somewhat familiar > with X window `geometry' specs, but there should be some mention or > xref to the meaning/use of `geometry' outside Emacs, or else this > parameter is unspecified in terms of its meaning or effect. > > And I cannot guess at all for `workarea'. What is it? How does/can > it differ from `geometry'? Perhaps an example will help. here is the output for a Windows machine with two monitors (of different sizes), arranged side by side: (display-monitor-attributes-list) ;; ==> (((geometry 0 0 1920 1080) ;; Left hand monitor (workarea 0 0 1920 1050) ;; Bottom edge of screen not available task bar (mm-size 677 381) (name . "\\\\.\\DISPLAY1") (frames # #)) ((geometry 1920 0 1680 1050) ;; Right hand monitor (workarea 1920 0 1680 1050) ;; Whole screen can be used (mm-size 593 370) (name . "\\\\.\\DISPLAY2") (frames))) The X,Y origin is at top left of the display, which spans both monitors. The Windows task bar is displayed across the bottom of the left hand monitor, so that space is reserved for Windows and is not available for display of emacs frames. For an emacs frame on the right-hand monitor: (frame-monitor-attributes) ;; ==> ((geometry 1920 0 1680 1050) (workarea 1920 0 1680 1050) (mm-size 593 370) (name . "\\\\.\\DISPLAY2") (frames #)) Does that help ? AndyM From unknown Mon Aug 18 04:45:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Oct 2014 18:24: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: To: Andy Moreton , 18637@debbugs.gnu.org Received: via spool by 18637-submit@debbugs.gnu.org id=B18637.14126198137219 (code B ref 18637); Mon, 06 Oct 2014 18:24:01 +0000 Received: (at 18637) by debbugs.gnu.org; 6 Oct 2014 18:23:33 +0000 Received: from localhost ([127.0.0.1]:35989 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbCwX-0001sN-9C for submit@debbugs.gnu.org; Mon, 06 Oct 2014 14:23:33 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:22179) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbCwU-0001sE-L8 for 18637@debbugs.gnu.org; Mon, 06 Oct 2014 14:23:31 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s96INTVW019499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Oct 2014 18:23:29 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s96INQlI024186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Oct 2014 18:23:28 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s96INQH4019118; Mon, 6 Oct 2014 18:23:26 GMT MIME-Version: 1.0 Message-ID: Date: Mon, 6 Oct 2014 11:23:24 -0700 (PDT) From: Drew Adams References: > <837g0dm95c.fsf@gnu.org>> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > Does that help ? Yes, the example helps me understand. Thanks. My comment, however, was that none of this is documented. It should be. What `geometry' and `workarea' mean should be specified. From unknown Mon Aug 18 04:45:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Oct 2014 19:30:03 +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: To: Drew Adams Cc: 18637@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 18637-submit@debbugs.gnu.org id=B18637.141262378813810 (code B ref 18637); Mon, 06 Oct 2014 19:30:03 +0000 Received: (at 18637) by debbugs.gnu.org; 6 Oct 2014 19:29:48 +0000 Received: from localhost ([127.0.0.1]:36014 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbDyd-0003ad-Kx for submit@debbugs.gnu.org; Mon, 06 Oct 2014 15:29:48 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:38498) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbDya-0003aT-Da for 18637@debbugs.gnu.org; Mon, 06 Oct 2014 15:29:45 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0ND100L00EYYQY00@a-mtaout23.012.net.il> for 18637@debbugs.gnu.org; Mon, 06 Oct 2014 22:29:42 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0ND100L27FHIQA30@a-mtaout23.012.net.il>; Mon, 06 Oct 2014 22:29:42 +0300 (IDT) Date: Mon, 06 Oct 2014 22:29:51 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <8361fxm1xs.fsf@gnu.org> References: X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Mon, 6 Oct 2014 10:25:31 -0700 (PDT) > From: Drew Adams > Cc: 18637@debbugs.gnu.org > > > > Which function tells you what monitor is showing a given frame (on > > > MS Windows)? > > > > frame-monitor-attributes, if I understand what you want. > > I see that that function returns some information about (attributes > of) the monitor that is most associated with the argument frame. And > I see that one of the attributes is `name'. Presumably, monitors > would be distinguished by this parameter. [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.175 listed in list.dnswl.org] 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.3 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) [URIs: oracle.com] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Mon, 6 Oct 2014 10:25:31 -0700 (PDT) > From: Drew Adams > Cc: 18637@debbugs.gnu.org > > > > Which function tells you what monitor is showing a given frame (on > > > MS Windows)? > > > > frame-monitor-attributes, if I understand what you want. > > I see that that function returns some information about (attributes > of) the monitor that is most associated with the argument frame. And > I see that one of the attributes is `name'. Presumably, monitors > would be distinguished by this parameter. [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.175 listed in list.dnswl.org] 0.3 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) [URIs: oracle.com] 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) > Date: Mon, 6 Oct 2014 10:25:31 -0700 (PDT) > From: Drew Adams > Cc: 18637@debbugs.gnu.org > > > > Which function tells you what monitor is showing a given frame (on > > > MS Windows)? > > > > frame-monitor-attributes, if I understand what you want. > > I see that that function returns some information about (attributes > of) the monitor that is most associated with the argument frame. And > I see that one of the attributes is `name'. Presumably, monitors > would be distinguished by this parameter. If you need to distinguish them, which should be very rarely. > However, it is an optional parameter, so I can't imagine that one can > count on it to distinguish monitors. (Just why is it optional?) I guess it's optional because not all windowing systems support it. It is always present on MS-Windows, AFAIK. > If one cannot count on `name', how is the identity of monitors > determined? Do you just go by the particular cons of attributes > that is returned by `frame-monitor-attributes'? Depends on what you need this for. From unknown Mon Aug 18 04:45:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Oct 2014 20:53:02 +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: To: Eli Zaretskii Cc: 18637@debbugs.gnu.org Received: via spool by 18637-submit@debbugs.gnu.org id=B18637.141262874921874 (code B ref 18637); Mon, 06 Oct 2014 20:53:02 +0000 Received: (at 18637) by debbugs.gnu.org; 6 Oct 2014 20:52:29 +0000 Received: from localhost ([127.0.0.1]:36026 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbFGe-0005gh-Hc for submit@debbugs.gnu.org; Mon, 06 Oct 2014 16:52:29 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:38193) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbFGa-0005gW-Gn for 18637@debbugs.gnu.org; Mon, 06 Oct 2014 16:52:25 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s96KqK9k030354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Oct 2014 20:52:22 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s96KqJWh004753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Oct 2014 20:52:19 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s96KqJSR004740; Mon, 6 Oct 2014 20:52:19 GMT MIME-Version: 1.0 Message-ID: Date: Mon, 6 Oct 2014 13:52:17 -0700 (PDT) From: Drew Adams References: <> <<837g0dm95c.fsf@gnu.org>> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > > Read it and its sections. You will find the information you want > > there. Skip whatever sounds not relevant or too low-level, and > > keep reading. Read the MSDN documentation I pointed to, the answers > > are there. I read it all. The closest thing I noticed as relevant to my question was the 2 bits below, in Multiple Display Monitors > About Multiple Display Monitors > Positioning Objects on Multiple Display Monitors: 1. CreateWindow(Ex) displays a window on the monitor that contains the largest part of the window. Maximizes on the monitor that contains the largest part of the window before it was minimized. I gather from that that perhaps the problem is that a larger portion of the displayed frame might be on the other monitor, in which case the frame gets displayed (only?) on the other monitor. I guess that would mean that frame-position coordinates (`left', `top') are then interpreted relative to that other monitor (?). Is that right? 2. To position an object on a multiple monitor system 1. Determine the appropriate monitor. 2. Get the coordinates to the monitor. 3. Position the object using the coordinates. This suggests that the position of the desired (target) monitor needs to be added to the frame position, to get it to be on the intended monitor. Was that your point? Here is what I guess I still do not understand. Are the values of `left' etc. frame parameters relative to just the virtual display (which is the envelope of all of the monitors, at least on Windows)? In that case they would be essentially absolute and not depend on which monitor the frame is shown in. That is what I would expect, from the fact that Emacs just "sees a single large desktop", as Stefan put it. 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. On the other hand, if `left' etc. are relative to the monitor in which the frame is shown then I guess my code would need to add the monitor position and size, to give coordinates that are absolute (i.e., relative to the virtual display, aka "desktop"). The Windows doc you pointed to also says that the primary monitor is not necessarily at the left. So if `left' etc were not absolute but relative to the monitor origin then maybe this is what happened: 1. The OP had a frame in the left monitor, but the right monitor was primary. Since the primary monitor has the virtual screen's origin at its top left, positions in the left monitor would have negative horizontal positions. Dunno whether that means they should also have negative `left' positions, for Emacs. If `left' etc. are relative to the virtual=20 screen then yes, they would. If `left' etc. is relative to the current monitor then no, they would not. 2. My maximize/restore code stored the values of `left' etc. for later restore/maximize, but if these values are relative to the current monitor, when restored they might be interpreted as relative to the primary monitor (since no monitor is specified). So the frame would jump to the monitor on the right. Is that possible? If so, why wouldn't the monitor for the frame remain the same? What determines which monitor gets used? > > If, after that, you still don't understand what could go wrong > > with your code, come back and ask more specific questions with specific > > code snippets. Right now, what you write and ask just shows how > > much of the background you are missing to start reasoning about > > this. > > > > The issues are not complicated once you understand how Windows > > treats multiple monitors. Hopefully you can see from the above a little more clearly what I still misunderstand. And hopefully you will be able to help me understand a bit better. The relevant code snippet is what I sent earlier (`frcmds-available-screen-pixel-bounds'), plus functions `maximize-frame' and `restore-frame', here: http://www.emacswiki.org/emacs-en/download/frame-cmds.el In those two commands I do the following. For `maximize-frame': 1. Save the current `left' etc. as parameters `restore-left' etc. 2. Calculate the available screen size, using `frcmds-available-screen-pixel-bounds'. 3. Set `left' and `top' both to 0 and `width' and `height' to the calculated screen size. For `restore-frame': Restore `left' etc. from the saved values `restore-left' etc. From unknown Mon Aug 18 04:45:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Oct 2014 15:15: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: To: Drew Adams Cc: 18637@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 18637-submit@debbugs.gnu.org id=B18637.141269489416303 (code B ref 18637); Tue, 07 Oct 2014 15:15:01 +0000 Received: (at 18637) by debbugs.gnu.org; 7 Oct 2014 15:14:54 +0000 Received: from localhost ([127.0.0.1]:36788 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbWTV-0004Es-3W for submit@debbugs.gnu.org; Tue, 07 Oct 2014 11:14:53 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:52695) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbWTQ-0004Ed-3g for 18637@debbugs.gnu.org; Tue, 07 Oct 2014 11:14:51 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0ND200300YBDCC00@a-mtaout22.012.net.il> for 18637@debbugs.gnu.org; Tue, 07 Oct 2014 18:14:46 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0ND2003ADYCMCA00@a-mtaout22.012.net.il>; Tue, 07 Oct 2014 18:14:46 +0300 (IDT) Date: Tue, 07 Oct 2014 18:14:57 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83tx3flxn2.fsf@gnu.org> References: X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Mon, 6 Oct 2014 13:52:17 -0700 (PDT) > From: Drew Adams > Cc: 18637@debbugs.gnu.org > > The closest thing I noticed as relevant to my question was the 2 bits > below, in Multiple Display Monitors > About Multiple Display Monitors > > Positioning Objects on Multiple Display Monitors: > > 1. > > CreateWindow(Ex) displays a window on the monitor that contains the > largest part of the window. Maximizes on the monitor that contains the > largest part of the window before it was minimized. > > I gather from that that perhaps the problem is that a larger portion > of the displayed frame might be on the other monitor, in which case > the frame gets displayed (only?) on the other monitor. 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. > 2. > > To position an object on a multiple monitor system > > 1. Determine the appropriate monitor. > 2. Get the coordinates to the monitor. > 3. Position the object using the coordinates. > > This suggests that the position of the desired (target) monitor > needs to be added to the frame position, to get it to be on the > intended monitor. But I think this is not enough: you need also make sure the size of the frame is such as to cause Windows decide to actually place the frame on that monitor. Because if the size is such that the largest portion of the window is on another monitor, you won't get what you want. Again, something to play with and report. > Here is what I guess I still do not understand. Are the values of > `left' etc. frame parameters relative to just the virtual display > (which is the envelope of all of the monitors, at least on Windows)? Yes, according to my reading of the code and the MSDN documentation. But again, actually trying that will bring a much more reliable information. > 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). > The Windows doc you pointed to also says that the primary monitor > is not necessarily at the left. So if `left' etc were not absolute > but relative to the monitor origin then maybe this is what happened: > > 1. The OP had a frame in the left monitor, but the right monitor was > primary. Since the primary monitor has the virtual screen's origin > at its top left, positions in the left monitor would have negative > horizontal positions. > > Dunno whether that means they should also have negative `left' > positions, for Emacs. If `left' etc. are relative to the virtual > screen then yes, they would. If `left' etc. is relative to the > current monitor then no, they would not. Again, my understanding is that they are relative to the visrtual coordinate system. > The relevant code snippet is what I sent earlier > (`frcmds-available-screen-pixel-bounds'), plus functions > `maximize-frame' and `restore-frame', here: > http://www.emacswiki.org/emacs-en/download/frame-cmds.el > > In those two commands I do the following. > > For `maximize-frame': > > 1. Save the current `left' etc. as parameters `restore-left' etc. > 2. Calculate the available screen size, using > `frcmds-available-screen-pixel-bounds'. > 3. Set `left' and `top' both to 0 and `width' and `height' to the > calculated screen size. > > For `restore-frame': > > Restore `left' etc. from the saved values `restore-left' etc. That's a lot of code, and I have no way of trying it. I think at this stage it is best for the user in question to try some simple code that reports frame coordinates and creates a frame given specific coordinates, and then see what that means for us. Oh, and I think this is no longer about the docs, so probably a new bug report is in order, specifically about restoring frames on multi-monitor displays. From unknown Mon Aug 18 04:45:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Oct 2014 18:14: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: To: Eli Zaretskii Cc: 18637@debbugs.gnu.org Received: via spool by 18637-submit@debbugs.gnu.org id=B18637.1412705587574 (code B ref 18637); Tue, 07 Oct 2014 18:14:01 +0000 Received: (at 18637) by debbugs.gnu.org; 7 Oct 2014 18:13:07 +0000 Received: from localhost ([127.0.0.1]:36866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbZFy-00009B-On for submit@debbugs.gnu.org; Tue, 07 Oct 2014 14:13:07 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:29854) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbZFv-000092-Fm for 18637@debbugs.gnu.org; Tue, 07 Oct 2014 14:13:04 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s97ID2MJ021821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Oct 2014 18:13:02 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s97ICu4C005542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Oct 2014 18:12:59 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s97ICuaY013882; Tue, 7 Oct 2014 18:12:56 GMT MIME-Version: 1.0 Message-ID: <41484edb-9aaa-4f56-bf46-4ab70b609aac@default> Date: Tue, 7 Oct 2014 11:12:56 -0700 (PDT) From: Drew Adams References: <> <> <<83tx3flxn2.fsf@gnu.org>> In-Reply-To: <<83tx3flxn2.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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > That's my understanding as well, but someone who has access to such > a system should actually try that and report back. >=20 > > I guess that would mean that frame-position coordinates (`left', > > `top') are then interpreted relative to that other monitor (?). > > Is that right? >=20 > 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? (Note too that I am using MS Windows, but the OP who reported the problem is, I think, not on Windows.) > > Here is what I guess I still do not understand. Are the values of > > `left' etc. frame parameters relative to just the virtual display > > (which is the envelope of all of the monitors, at least on > > Windows)? >=20 > Yes, according to my reading of the code and the MSDN documentation. > But again, actually trying that will bring a much more reliable > information. >=20 > > 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. >=20 > 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. > > The Windows doc you pointed to also says that the primary monitor > > is not necessarily at the left. So if `left' etc were not > > absolute but relative to the monitor origin then maybe this is what > > happened: > > > > 1. The OP had a frame in the left monitor, but the right monitor > > was primary. Since the primary monitor has the virtual screen's > > origin at its top left, positions in the left monitor would have > > negative horizontal positions. > > > > Dunno whether that means they should also have negative `left' > > positions, for Emacs. If `left' etc. are relative to the > > virtual screen then yes, they would. If `left' etc. is relative > > to the current monitor then no, they would not. >=20 > Again, my understanding is that they are relative to the visrtual > coordinate system. >=20 > > The relevant code snippet is what I sent earlier > > (`frcmds-available-screen-pixel-bounds'), plus functions > > `maximize-frame' and `restore-frame', here: > > http://www.emacswiki.org/emacs-en/download/frame-cmds.el > > > > In those two commands I do the following. > > > > For `maximize-frame': > > > > 1. Save the current `left' etc. as parameters `restore-left' etc. > > 2. Calculate the available screen size, using > > `frcmds-available-screen-pixel-bounds'. > > 3. Set `left' and `top' both to 0 and `width' and `height' to the > > calculated screen size. > > > > For `restore-frame': > > > > Restore `left' etc. from the saved values `restore-left' etc. >=20 > 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 > I think at this stage it is best for the user in question to try > some simple code that reports frame coordinates and creates a frame > given specific coordinates, and then see what that means for us. I've sent him a mail, but I don't know whether he will have the time or interest to follow up on this. > Oh, and I think this is no longer about the docs, so probably a new > bug report is in order, specifically about restoring frames on > multi-monitor displays. Agreed. And thanks for your input. From unknown Mon Aug 18 04:45:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Oct 2014 18:27:02 +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: To: Drew Adams Cc: 18637@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 18637-submit@debbugs.gnu.org id=B18637.14127063771833 (code B ref 18637); Tue, 07 Oct 2014 18:27:02 +0000 Received: (at 18637) by debbugs.gnu.org; 7 Oct 2014 18:26:17 +0000 Received: from localhost ([127.0.0.1]:36871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbZSi-0000TU-PX for submit@debbugs.gnu.org; Tue, 07 Oct 2014 14:26:17 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:50945) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbZSf-0000TJ-Ry for 18637@debbugs.gnu.org; Tue, 07 Oct 2014 14:26:15 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0ND300B006YBCV00@mtaout27.012.net.il> for 18637@debbugs.gnu.org; Tue, 07 Oct 2014 21:20:54 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0ND3005BJ6YTGQ50@mtaout27.012.net.il>; Tue, 07 Oct 2014 21:20:54 +0300 (IDT) Date: Tue, 07 Oct 2014 21:26:23 +0300 From: Eli Zaretskii In-reply-to: <41484edb-9aaa-4f56-bf46-4ab70b609aac@default> X-012-Sender: halo1@inter.net.il Message-id: <8361fvlos0.fsf@gnu.org> References: <83tx3flxn2.fsf@gnu.org> <41484edb-9aaa-4f56-bf46-4ab70b609aac@default> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 7 Oct 2014 11:12:56 -0700 (PDT) > From: Drew Adams > 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. From unknown Mon Aug 18 04:45:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Oct 2014 18: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: To: Eli Zaretskii , Drew Adams Cc: 18637@debbugs.gnu.org Received: via spool by 18637-submit@debbugs.gnu.org id=B18637.14127067032433 (code B ref 18637); Tue, 07 Oct 2014 18:32:01 +0000 Received: (at 18637) by debbugs.gnu.org; 7 Oct 2014 18:31:43 +0000 Received: from localhost ([127.0.0.1]:36881 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbZXy-0000dA-Ro for submit@debbugs.gnu.org; Tue, 07 Oct 2014 14:31:43 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:41356) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbZXw-0000d2-E6 for 18637@debbugs.gnu.org; Tue, 07 Oct 2014 14:31:40 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s97IVamg013287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Oct 2014 18:31:39 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s97IVZJj005351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Oct 2014 18:31:36 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s97IVZTW010326; Tue, 7 Oct 2014 18:31:35 GMT MIME-Version: 1.0 Message-ID: <8240acb2-9976-4e39-bb3f-2ea1852803ce@default> Date: Tue, 7 Oct 2014 11:31:34 -0700 (PDT) From: Drew Adams References: <> <> <<83tx3flxn2.fsf@gnu.org>> <<41484edb-9aaa-4f56-bf46-4ab70b609aac@default>> <<8361fvlos0.fsf@gnu.org>> In-Reply-To: <<8361fvlos0.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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > 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. Yeah, me too, on both accounts. > > > 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 >=20 > No, I meant I have no access to a system with more than one monitor. Me neither. I filed bug #18657 for this issue. From unknown Mon Aug 18 04:45:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows In-Reply-To: <12fc196e-cc82-4f22-8d2f-cede95542ea7@default> Resent-From: Andy Moreton Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Oct 2014 18:37: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: To: 18637@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.14127069662855 (code B ref -1); Tue, 07 Oct 2014 18:37:01 +0000 Received: (at submit) by debbugs.gnu.org; 7 Oct 2014 18:36:06 +0000 Received: from localhost ([127.0.0.1]:36890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbZcD-0000jy-0q for submit@debbugs.gnu.org; Tue, 07 Oct 2014 14:36:05 -0400 Received: from eggs.gnu.org ([208.118.235.92]:44853) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbZc9-0000jm-V9 for submit@debbugs.gnu.org; Tue, 07 Oct 2014 14:36:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XbZc1-0004kh-TD for submit@debbugs.gnu.org; Tue, 07 Oct 2014 14:36:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:49889) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbZc1-0004kd-Pf for submit@debbugs.gnu.org; Tue, 07 Oct 2014 14:35:53 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbZbv-0000LW-H9 for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2014 14:35:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XbZbp-0004jJ-8A for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2014 14:35:47 -0400 Received: from plane.gmane.org ([80.91.229.3]:58194) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbZbo-0004j7-P1 for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2014 14:35:40 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XbZbn-00056Y-5I for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2014 20:35:39 +0200 Received: from uk.solarflare.com ([193.34.186.16]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Oct 2014 20:35:39 +0200 Received: from andrewjmoreton by uk.solarflare.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Oct 2014 20:35:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ From: Andy Moreton Date: Tue, 07 Oct 2014 19:35:28 +0100 Lines: 66 Message-ID: References: <83tx3flxn2.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: uk.solarflare.com User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.94 (windows-nt) Cancel-Lock: sha1:mOBm0E12ZCCYrBsBlvFinG8oHRI= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.1 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.1 (----) On Tue 07 Oct 2014, Eli Zaretskii wrote: >> The relevant code snippet is what I sent earlier >> (`frcmds-available-screen-pixel-bounds'), plus functions >> `maximize-frame' and `restore-frame', here: >> http://www.emacswiki.org/emacs-en/download/frame-cmds.el> >> In those two commands I do the following. >> >> For `maximize-frame': >> >> 1. Save the current `left' etc. as parameters `restore-left' etc. >> 2. Calculate the available screen size, using >> `frcmds-available-screen-pixel-bounds'. >> 3. Set `left' and `top' both to 0 and `width' and `height' to the >> calculated screen size. >> >> For `restore-frame': >> >> Restore `left' etc. from the saved values `restore-left' etc. > > That's a lot of code, and I have no way of trying it. I have a multi-monitor system, but I'm not going to perform experiments without a clearer recipe. I did try rearranging the physical monitor layout as follows (which makes it quite easy to lose the position of the cursor). Things may get more confusing with three or more monitors... ;; Two monitors arranged physically as: ;; +---------+ ;; | | ;; | 2 |+---------+ ;; | || | ;; +---------+| 1 | ;; | | ;; +---------+ (display-monitor-attributes-list) ;; ==> (((geometry 0 0 1920 1080) (workarea 0 0 1920 1050) (mm-size 677 381) (name . "\\\\.\\DISPLAY1") (frames)) ((geometry -1680 -646 1680 1050) (workarea -1680 -646 1680 1050) (mm-size 593 370) (name . "\\\\.\\DISPLAY2") (frames))) (display-pixel-height) ;; ==> 1726 (display-pixel-width) ;; ==> 3600 (display-mm-height) ;; ==> 609 (display-mm-width) ;; ==> 1269 > I think at this stage it is best for the user in question to try some > simple code that reports frame coordinates and creates a frame given > specific coordinates, and then see what that means for us. > > Oh, and I think this is no longer about the docs, so probably a new > bug report is in order, specifically about restoring frames on > multi-monitor displays. True, as long as the meaning of geometry/workarea and the coordinate system are given a little more detail in the docs. AdnyM From unknown Mon Aug 18 04:45:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Oct 2014 20:26:02 +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: To: Andy Moreton , 18637@debbugs.gnu.org Received: via spool by 18637-submit@debbugs.gnu.org id=B18637.141271354613463 (code B ref 18637); Tue, 07 Oct 2014 20:26:02 +0000 Received: (at 18637) by debbugs.gnu.org; 7 Oct 2014 20:25:46 +0000 Received: from localhost ([127.0.0.1]:36943 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbbKK-0003V3-W3 for submit@debbugs.gnu.org; Tue, 07 Oct 2014 16:25:45 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:37435) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbbKJ-0003Uv-1G for 18637@debbugs.gnu.org; Tue, 07 Oct 2014 16:25:43 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s97KPfs4027659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Oct 2014 20:25:42 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s97KPeRT009294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Oct 2014 20:25:41 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s97KPepA020706; Tue, 7 Oct 2014 20:25:40 GMT MIME-Version: 1.0 Message-ID: Date: Tue, 7 Oct 2014 13:25:40 -0700 (PDT) From: Drew Adams References: <83tx3flxn2.fsf@gnu.org> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > I have a multi-monitor system, but I'm not going to perform > experiments without a clearer recipe. I did try rearranging the physical > monitor layout as follows (which makes it quite easy to lose the position > of the cursor). Things may get more confusing with three or more monitors= ... >=20 > ;; Two monitors arranged physically as: > ;; +---------+ > ;; | | > ;; | 2 |+---------+ > ;; | || | > ;; +---------+| 1 | > ;; | | > ;; +---------+ > (display-monitor-attributes-list) > ;; =3D=3D> > (((geometry 0 0 1920 1080) > (workarea 0 0 1920 1050) > (mm-size 677 381) > (name . "\\\\.\\DISPLAY1") > (frames)) > ((geometry -1680 -646 1680 1050) > (workarea -1680 -646 1680 1050) > (mm-size 593 370) > (name . "\\\\.\\DISPLAY2") > (frames))) >=20 > (display-pixel-height) ;; =3D=3D> 1726 > (display-pixel-width) ;; =3D=3D> 3600 >=20 > (display-mm-height) ;; =3D=3D> 609 > (display-mm-width) ;; =3D=3D> 1269 Thanks for the offer, Andy. I don't have a better recipe to give, unfortunately. I've mentioned in this thread all of the info I have. I think it might be enough if you tried the `maximize-frame' and `restore-frame' commands in frame-cmds.el, especially if (I'm guessing, based on the conversation with Eli) you have one monitor that is smaller than the other. It sounds like perhaps you will see a frame that you maximize or restore this way jump from one frame to another. Perhaps that will happen more if most of the frame before the operation is in fact shown on the other frame. But the OP did not mention that. His report seemed to suggest that the frame was shown completely in one frame and then jumped to another frame when it was maximized (or restored?). The frame-cmds.el code just changes frame parameters `left', `top', `width', and `height'. In principle, restoring just resets the original values for these, and maximizing sets them to values that fill the screen (which is not necessarily the same thing as the monitor). From unknown Mon Aug 18 04:45:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18637: bug#18657: 24.4.50; positioning frames on multi-monitor displays Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Jul 2021 22:01:02 +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: To: Drew Adams Cc: 18657@debbugs.gnu.org, 18637@debbugs.gnu.org Received: via spool by 18637-submit@debbugs.gnu.org id=B18637.162621364716970 (code B ref 18637); Tue, 13 Jul 2021 22:01:02 +0000 Received: (at 18637) by debbugs.gnu.org; 13 Jul 2021 22:00:47 +0000 Received: from localhost ([127.0.0.1]:42259 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3QSN-0004Pd-CE for submit@debbugs.gnu.org; Tue, 13 Jul 2021 18:00:47 -0400 Received: from quimby.gnus.org ([95.216.78.240]:35732) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3QSK-0004PK-3N; Tue, 13 Jul 2021 18:00:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=rfaD1A5spx5jGuqJ8Znj3eVufo0ls02KZUugVJF+Ttc=; b=kmk+xZR4v/GGE6gRvRo2RIFOfl U+AeFqEWhWVP8YOaTPTjKKGKQhcgUr39D+CpWXKoaS6pSqgdT9aBqnV2AVGtP9Eisi8kFD2AVtzw1 fwEPgzlSJ4v+j+8Om0XPigrDElAXHsVVR4+fiRlzoqmvNSsRtMjc5DFXWA1XbQph4Y58=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m3QRs-0004xK-33; Wed, 14 Jul 2021 00:00:26 +0200 From: Lars Ingebrigtsen References: <9a22e7a5-0b06-4ca3-8698-11dfebd8e62d@default> <539e4d69-89e1-4be0-8c33-3f916400fbdc@default> X-Now-Playing: ANNA's _Kompakt Total 19 (2)_: "Remembrance (Main Mix)" Date: Wed, 14 Jul 2021 00:00:15 +0200 In-Reply-To: <539e4d69-89e1-4be0-8c33-3f916400fbdc@default> (Drew Adams's message of "Tue, 7 Oct 2014 14:18:13 -0700 (PDT)") Message-ID: <877dhtoowg.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Drew Adams writes: > Based on that, I've sent him an updated version of `maximize-frame' > (from `frame-cmds.el'), which differs only in not using (0, 0) as the > position coordinates systematically. Instead, it uses thi [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Drew Adams writes: > Based on that, I've sent him an updated version of `maximize-frame' > (from `frame-cmds.el'), which differs only in not using (0,0) as the > position coordinates systematically. Instead, it uses this: > > (nth 1 (assq 'workarea (frame-monitor-attributes frame))) ; For left > (nth 2 (assq 'workarea (frame-monitor-attributes frame))) ; For right > > Andy, perhaps you could try that? There doesn't really seem to be anything actionable in this bug report, and not a lot in the parent report #18637, either. I think for any progress to be made here, a report describing what problem's you're seeing (if any, these days), and what you think should be done about it should be filed. But I'm closing this report and #18637. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 13 18:01:06 2021 Received: (at control) by debbugs.gnu.org; 13 Jul 2021 22:01:06 +0000 Received: from localhost ([127.0.0.1]:42272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3QSg-0004RW-1f for submit@debbugs.gnu.org; Tue, 13 Jul 2021 18:01:06 -0400 Received: from quimby.gnus.org ([95.216.78.240]:35748) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3QSe-0004QK-Vk for control@debbugs.gnu.org; Tue, 13 Jul 2021 18:01:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=s3wusMTTZFclj6CYLyESNBAV0OIuTAQaG9pgOdJG5vo=; b=L0WQIodDQZcNjiADlDas3eV42p zWW8EY7HpR86WiUUxqB6pK9rV5G4SPH99FGQ80yRokF0AmII/gGEQjEacAI/NaLwKocPNv13jJQC2 Do6+fIERZs6H8VIlFSjWxpeTAZyjxkp/+bC3RyUL0Okmvl4KGLU7QbhxizWLvrbxJdoY=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m3QSX-000508-8Z for control@debbugs.gnu.org; Wed, 14 Jul 2021 00:00:59 +0200 Date: Wed, 14 Jul 2021 00:00:56 +0200 Message-Id: <874kcxoovb.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #18637 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 18637 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 18637 quit From unknown Mon Aug 18 04:45:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18637: [External] : Re: bug#18657: 24.4.50; positioning frames on multi-monitor displays Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Jul 2021 22:21:02 +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: To: Lars Ingebrigtsen Cc: "18657@debbugs.gnu.org" <18657@debbugs.gnu.org>, "18637@debbugs.gnu.org" <18637@debbugs.gnu.org> Received: via spool by 18637-submit@debbugs.gnu.org id=B18637.162621484927271 (code B ref 18637); Tue, 13 Jul 2021 22:21:02 +0000 Received: (at 18637) by debbugs.gnu.org; 13 Jul 2021 22:20:49 +0000 Received: from localhost ([127.0.0.1]:42308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3Qlk-00075i-Q3 for submit@debbugs.gnu.org; Tue, 13 Jul 2021 18:20:49 -0400 Received: from mx0b-00069f02.pphosted.com ([205.220.177.32]:39586) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3Qlg-00075S-QN; Tue, 13 Jul 2021 18:20:47 -0400 Received: from pps.filterd (m0246630.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16DMHU9a026479; Tue, 13 Jul 2021 22:20:44 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2020-01-29; bh=5Dfu3ZifBSU0+jmdJa7EN6m77K4+WDJqbxG1+Rrk9ik=; b=ihcyjPYyOxYrNjT0f8nJwvrxAHjZmrF05jWhZne/t8xsA2fMYSWuky1xBMV2WirirNpl M0noyOeKmZw9VK2RlxRMcqFLt1+gud/x2eIx4U86pmphQrjcBbtSyoPih+Px1NbcRMEc FevN59vRqT4r9vCAAqbehfErM94vOrZ6qKgzylyKRW8UNu3vj+0mMSLL4KQMXFLfNytm ILACM3gK0Mb9G4+Uwf6w5MiGynocYFzgBWdc+/+kevEAsn3+Dxyn6fz08Hr8rncCy8TN A1XKST/cKDQVrAykVL0lS3/dxQ+TWc1tTEckb37YRSTX9RFTTck98OpW/AgC2KHwn6DD hQ== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by mx0b-00069f02.pphosted.com with ESMTP id 39rnxdkn0f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 13 Jul 2021 22:20:44 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 16DMGlAN113323; Tue, 13 Jul 2021 22:20:43 GMT Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2177.outbound.protection.outlook.com [104.47.57.177]) by userp3030.oracle.com with ESMTP id 39q0p63ej1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 13 Jul 2021 22:20:42 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f/vSvCoULGOaXCvsjGdM0tpCzbKPslsYfh0GJflz4MIllaJbcOwOxlaCE8ib88vjoMBrejjNefuEVhzOhuQPEf16lwGHNYTlkjZF3+aL2nruHRcHKtbNbITtD3sj4azeMH2U7ZbCMnmsnBUuFf3zJ+Wb7J71Zr8252J5oEKuUvC/U4vS7SG9pbZmeNl9fk+5JJepDvR0/3wRVIBKPpe7i0dwDBQnQYqEa8RKMOq0XRpL9pcw+FZ0qUWzUP/HzzW9JdtDq92KGsUn5yYE3WAhVG+bsAw7K/6sCarSJI55lPx+v+9gSfQQRFzAN732kI6vHsidlwABABn+98iIQFbsTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5Dfu3ZifBSU0+jmdJa7EN6m77K4+WDJqbxG1+Rrk9ik=; b=N3xBdtg9UkQ1paj1nWU7bSC567IeLDks+A0al+QcvtszJ84cvbJyt9pToOdFmT+wvLJLzFajgi/KCBWthGI/8A1k/PQ6DrtSk6pcFuRZETmoa+8AfJ/bEmd1IbkzIHjKSsM1ZPgiM1UP5MKutTI8Ucosws0d4hs0Xdq5aDLrapDNAR9fyCSNDlmbcMJeCF+1QWSyDMpel6zYo4C/+DnJ2RrMfOCOkwEYN9yomDggSciVq5vQi3gPHpV496ZgmUeJN7hkPYHm6FDs2t7vequJsO8hW4zsH6DCbyBGR9Tm33C5tblDUoBY0ybLbKdm2iv4loUmkSIn8Zqr/cbqw2FQiQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5Dfu3ZifBSU0+jmdJa7EN6m77K4+WDJqbxG1+Rrk9ik=; b=Mu+9Ti2MauY6cTgM47Cu67UtVWW3FMId28zJYTB9OdXYCnPnTdWnnCNCk96aq+gzXUi2AZ9g3hVaAtx4vB1xqVqgaE/mkAix9UKM/M3BooO1WZKgXJ4eKOLfxa0DNkRCTqPJ+wzRcXRDrC6jjK8S0g0mcdsuOoPc523kKn6QQ7Q= Received: from SJ0PR10MB5488.namprd10.prod.outlook.com (2603:10b6:a03:37e::19) by BY5PR10MB4131.namprd10.prod.outlook.com (2603:10b6:a03:206::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.21; Tue, 13 Jul 2021 22:20:41 +0000 Received: from SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::1d3c:d31b:8add:1958]) by SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::1d3c:d31b:8add:1958%5]) with mapi id 15.20.4308.027; Tue, 13 Jul 2021 22:20:41 +0000 From: Drew Adams Thread-Topic: [External] : Re: bug#18657: 24.4.50; positioning frames on multi-monitor displays Thread-Index: AQHXeDKHuOLcn+k5lEqQVi2q0cjLeqtBeYmg Date: Tue, 13 Jul 2021 22:20:41 +0000 Message-ID: References: <9a22e7a5-0b06-4ca3-8698-11dfebd8e62d@default> <539e4d69-89e1-4be0-8c33-3f916400fbdc@default> <877dhtoowg.fsf@gnus.org> In-Reply-To: <877dhtoowg.fsf@gnus.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gnus.org; dkim=none (message not signed) header.d=none;gnus.org; dmarc=none action=none header.from=oracle.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9875c7e3-1628-45f1-777e-08d9464c7329 x-ms-traffictypediagnostic: BY5PR10MB4131: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pUm/xnbRkVselKDsSju8maSkzh+w0WylJMEHyE36qJJuo2YV+jh9izeYPDWgjE6TdbescwO/xBDYcEDkBjfuKJy2QqlMDSngTm2MZRMIyj0sVuBC+I/xcYfSZkbtY2DAJcRbUo0qVzbu3V2yeA9BSx4HxPjn/pR65VIna9ekE06upZri6++aO/tVg+8H/reNjpKcXrN3e6OOcy1cQcMYDSmKJL/MG4wQ0LFBQtpQdAO74UeXYkOzVExFwYlYvfsn9sD37Er5K9r2n8IOJuqQ4O93WzlXGEi4qfGdcqSvcx3HOS8zjEwUNtxAMvUhFtT0xfAao1gZPTqvly35tT61fmL+NrSJ5QnFFJKXE/Be+/dXdsB3J1OjC6kPQaUtScj0UYVD71sfnjiTHi98nzMfiJUiGXc+E0iEam+PNzL+bl04+Fr7Mz1iulrisshmcnXrc+jslVs0q9rnQtbBM1bK4lhsZcTXfgjEdcw22ANQgPFXACcgQGpRewYEFTSDCrWQ/IOzFqXBqHzLE6vNg6vQJptwUrWlpSfvzuq+1vWO7Az+C5RDtF1s+Dn057Qvb9oPL0QwAOkPXFTtMfBI2sAm0RKY5v89wJ3zsOAquiroHE5ETzZAxur1hyt4d5xqJwjhewXgcZcB+dY3JVeedZv/7RcTxr+2qOQDP7gMYwjHyG0ktTIfxPjzpvKwM+7WedSAod8gUguXfbg0pTH8dyK+FA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR10MB5488.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(346002)(376002)(39860400002)(396003)(136003)(26005)(478600001)(66446008)(54906003)(9686003)(38100700002)(2906002)(71200400001)(8936002)(316002)(186003)(7696005)(6506007)(122000001)(55016002)(64756008)(8676002)(5660300002)(33656002)(4326008)(66476007)(66946007)(76116006)(6916009)(4744005)(44832011)(52536014)(86362001)(66556008)(38070700003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: V4VkjXyiNw4RQV2ahBcT65sFaD4PqHe0iFH0aci0Xfnz0j3yWtcGhaU8wWN7cpYeXMDrWUg+VdO268zNmxHkudxgZG+bBlhdCSl+K6LSrCUbcKK6PLpBQmm6j5ikpqozrS5o+eUKFw72MhQKVFbImycoRwzyK4gp982stzQ3kjVh4CeNjPqC3n06WE04zKiFcCyP8jjPoZ8IPnCu9A0REHk1xPY7lW7mnW7Nj56Cf1KaOPZC5dyBIMQYT+Uc+/BUWJb5kG9HniNz4TnzQ8tJpKQpkSmtPCIY5/558hoFSSTcpsoaN4KsC6wI/FMS4JLAqNWKDIsYxfRvPG448k6dTS2fHp/0wnZsbDz3Z0S4HBrQ89S9fpAT+jmZDTje5+MuSM5QW9Z6/PKHtSmtiDRB53Sh6gHpS26iYWwo7LCumG6+QyLouh7vrDBoJpznAltdCio0jJx1fY3uf3JwPGJtJ9hmAFfU132GsU51GcFiuNuLioUGtxuLfUYtfbT+SwTaHkMYS4v3zBdk4RNh5bfSm0oJuKG8WNLL+t80iq4hFeNjdJd5N4vQUQtHDFfeCEoWFlUojBGNGRnBRlup7NPLfbcYOxcYt17OJhhl8i82TGE7iaFRyTv4qvfDdEkXw7zinG6TeJugDYzT22pw91PKDewj0Gv6kqCe5ggWiwWsLB4PCYcqyWkWfma97+JylHZmdqcF6gmn5ZAv67yNe/dtv0WNGkWSEnszcUyUmR4TCgia69PdEtBzSxbJ/XgdLLfbkMtcHSLj5HyQ1apQW3Y/39WdG1ZmP0J4f0jQBvg4jisyf8fqPQzAg04psHrNV2T/QGb9SxK3lGKi04xgI7/sTOnnJc+TGMz3au0D1/H3vkWaS/J6uSUuR2gVMo89S7wJ5J7Ws93awVDHmKMzelS4dywMhFO7yMZ4zN/z4uS2JoZLkuJ3DU19YFmt75jj1aBRsRA2tX9qyDQahpk0byFNKZ6g9TxGqTokPhME8guk78ZMjHqg/UUY2qauxJW1lddxTAe6n8vk9+C2Hl+ovkMQQ3amIcicFzamkKmvF1VtAF9gErLCy12bKoL7g1/vTimOipVl71ZXU2FaQFsAhEuyR4hHsMjVnjvG2debGWooHUMylbEpzN5lGxSqaGdubpsiEzvrxm3XWaCG7Z0r+fl8pVfaj5+YnGlLBUyW0cgCHqJmLQ2eQM4kZISo14YOdUAkB2xJUZwBTO8IZggQuB5TmOEjwlBdWiTOkDpv3kLGUir7yxIgN/emron6jEQkMU3I+ubUBFKSVstimIApMhoMbE/7rRxFcU+q7f9ZbsqqKpI= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB5488.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9875c7e3-1628-45f1-777e-08d9464c7329 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2021 22:20:41.2076 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yim5K52xsDn44S5py1xVZinbQKrlBY4LiTS2qlPCsj8sTN6YQnmkFdVMis0kVEPMPdJND69Sp8/0ZNYWP1RTjA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR10MB4131 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=10044 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 phishscore=0 spamscore=0 bulkscore=0 mlxlogscore=792 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107130136 X-Proofpoint-GUID: iObBk1JYMW6xj61CN8ZlQrFZCK7bheGA X-Proofpoint-ORIG-GUID: iObBk1JYMW6xj61CN8ZlQrFZCK7bheGA X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > There doesn't really seem to be anything actionable in this bug report, > and not a lot in the parent report #18637, either. >=20 > I think for any progress to be made here, a report describing what > problem's you're seeing (if any, these days), and what you think should > be done about it should be filed. But I'm closing this report and #18637= . Yet another "won't fix". At least one other user (Andy M) agreed in these threads that "the meaning of geometry/workarea and the coordinate system [need to be] given a little more detail in the docs." Alas, the docs weren't touched (AFAIK). Too bad.