From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fran Litterio Newsgroups: gmane.emacs.devel Subject: Re: Bug in function =?utf-8?b?eF9jYWxjX2Fic29sdXRlX3Bvc2l0aW9u?= =?utf-8?b?aW4JeHRlcm0uYw==?= and w32term.c Date: Tue, 30 Jun 2015 13:42:17 +0000 (UTC) Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1435671769 28485 80.91.229.3 (30 Jun 2015 13:42:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Jun 2015 13:42:49 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 30 15:42:41 2015 Return-path: Envelope-to: ged-emacs-devel@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 1Z9vo5-0004ST-0p for ged-emacs-devel@m.gmane.org; Tue, 30 Jun 2015 15:42:37 +0200 Original-Received: from localhost ([::1]:47087 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9vo4-0005tQ-Ha for ged-emacs-devel@m.gmane.org; Tue, 30 Jun 2015 09:42:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53097) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9vnx-0005sL-Pw for emacs-devel@gnu.org; Tue, 30 Jun 2015 09:42:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z9vnu-0006rC-So for emacs-devel@gnu.org; Tue, 30 Jun 2015 09:42:29 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:47147) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9vnu-0006qt-M2 for emacs-devel@gnu.org; Tue, 30 Jun 2015 09:42:26 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Z9vnr-0004Kl-9h for emacs-devel@gnu.org; Tue, 30 Jun 2015 15:42:23 +0200 Original-Received: from interv03.i.subnet.rcn.com ([146.115.9.234]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Jun 2015 15:42:23 +0200 Original-Received: from flitterio by interv03.i.subnet.rcn.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Jun 2015 15:42:23 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 35 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 146.115.9.234 (Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.130 Safari/537.36) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:187666 Archived-At: I wrote: > Using the latest sources, I see the following behavior on a machine > with two 1920x1080 monitors arranged side-by-side: > > $ runemacs.exe -Q ... > (setq f (make-frame '((left . -1)))) > # IZSYSTEM023 015257f0> > (frame-parameter f 'left) > 3155 > > The left offset of the new frame appears to be 1920 pixels too far > to the right. Evaluating the following form positions the frame to > its expected location (abutting the right edge of the rightmost > monitor): > > (set-frame-position f (- 3155 1920) 0) I've learned that this only happen when the 2nd monitor is positioned to the left of the primary Windows monitor, resulting in negative X offsets for frames on the 2nd monitor. If I configure Windows to position the 2nd monitor to the right of the primary monitor, all X offsets are positive, and the first form above works as expected (the new frame abuts the far right edge of the combined monitors). I still believe the fix should be made in x_calc_absolute_position, but it must now take into consideration whether X offset 0 is within the multi-monitor display or at the far left edge. I still hope to create a patch to fix this problem. -- Fran Litterio flitterio@gmail.com