From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows Date: Tue, 7 Oct 2014 11:12:56 -0700 (PDT) Message-ID: <41484edb-9aaa-4f56-bf46-4ab70b609aac@default> References: <> <> <<83tx3flxn2.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1412705669 12917 80.91.229.3 (7 Oct 2014 18:14:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Oct 2014 18:14:29 +0000 (UTC) Cc: 18637@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 07 20:14:23 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XbZHC-00052y-1T for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Oct 2014 20:14:22 +0200 Original-Received: from localhost ([::1]:60293 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbZHB-00032w-IY for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Oct 2014 14:14:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41363) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbZH1-000326-Ae for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2014 14:14:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XbZGs-0005SB-DR for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2014 14:14:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45302) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbZGs-0005S7-9n for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2014 14:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XbZGr-0000Ac-PG for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2014 14:14:01 -0400 X-Loop: help-debbugs@gnu.org 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: Original-Received: via spool by 18637-submit@debbugs.gnu.org id=B18637.1412705587574 (code B ref 18637); Tue, 07 Oct 2014 18:14:01 +0000 Original-Received: (at 18637) by debbugs.gnu.org; 7 Oct 2014 18:13:07 +0000 Original-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 Original-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 Original-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 Original-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 Original-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 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)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:94251 Archived-At: > 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.