bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[Francis Litterio]

On Windows, using Emacs built from the latest source, I see the following
behavior on a machine with two 1920x1080 monitors arranged side-by-side, such
that the right monitor is the primary monitor (i.e., the monitor on which the
taskbar is drawn).  This monitor arrangement gives frames on the left monitor
negative X offsets, which is why this bug happens.

  $ runemacs.exe -Q

In buffer *scratch*:

  (setq f (make-frame '((left . -1))))
  #<frame emacs <at> 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 right monitor):

  (set-frame-position f (- 3155 1920) 0)

The root cause appears to be that function x_calc_absolute_position (in
xterm.c and w32term.c) calls function x_display_pixel_width to obtain the
combined pixel width of all monitors, but the code doesn't take into account
that one (or more) monitors might have negative X offsets, which can happen on
Windows.  Thus, the new frame's left offset is miscomputed.

Under the X window system, I'm not sure if monitors can have negative X offsets,
so this may not be an issue under X.

I suspect the same problem would happen when making a frame with a 'top
parameter of -1 when the non-primary monitor is positioned above the primary
monitor (i.e., has negative Y offsets).
--
Fran Litterio
flitterio <at> gmail.com



In GNU Emacs 25.0.50.4 (i686-pc-mingw32)
 of 2015-06-30 on PUPPY
Repository revision: 5f004117f5bcab9171eaddb2867393ed69ae49bf
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=c:/apps/emacs --without-x --without-xpm
 --without-png --without-jpeg --without-tiff --without-gif'

Configured features:
SOUND NOTIFY ACL TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: C.ISO-8859-1
  locale-coding-system: cp1252

Major mode: Text

Minor modes in effect:
  erc-list-mode: t
  erc-menu-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-track-minor-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-netsplit-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  diff-auto-refine-mode: t
  show-paren-mode: t
  save-place-mode: t
  icomplete-mode: t
  savehist-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  auto-fill-function: do-auto-fill
  transient-mark-mode: t
  abbrev-mode: t

Recent messages:
Wrote c:/franl/emacs-bug.txt
Saving file c:/franl/emacs-bug.txt...
Wrote c:/franl/emacs-bug.txt
Saving file c:/franl/emacs-bug.txt...
Wrote c:/franl/emacs-bug.txt
Saving file c:/franl/emacs-bug.txt...
Wrote c:/franl/emacs-bug.txt
Mark set [2 times]
Quit
(No changes need to be saved)

Load-path shadows:
None found.

Features:
(rfc2104 mailalias pulse jka-compr find-func sh-script smie executable
shadow mail-extr emacsbug calc-alg calc-aent calc-menu rect misearch
multi-isearch edmacro kmacro server sort gnus-draft gnus-agent gnus-srvr
nnvirtual nndraft nnmh gnus-msg gnus-cite canlock gnus-art mm-uu mml2015
epg-config mm-view mml-smime smime dig mailcap gnus-async gnus-score
score-mode gnus-cache gnus-sum fpl-moo fpl-react erc-notify erc-truncate
erc-log erc-dcc erc-list erc-menu erc-join erc-ring erc-networks
erc-pcomplete erc-track erc-match erc-button erc-fill erc-stamp
erc-netsplit erc-goodies erc erc-backend erc-compat thingatpt help-mode
source-safe ediff-merg ediff-wind ediff-diff ediff-mult ediff-help
ediff-init ediff-util ediff grep python json ielm pp sgml-mode
csharp-mode cc-langs cl smtpmail sendmail nntp gnus-group gnus-undo
gnus-start gnus-cloud nnimap nnmail mail-source utf7 netrc parse-time
gnus-spec gnus-int gnus-range message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums
mailabbrev gmm-utils mailheader gnus-win nnoo gnus gnus-ems nnheader
mail-utils wid-edit etags vc vc-dispatcher dired-aux hexl smerge-mode
diff-mode easy-mmode paren man info compile apropos tramp tramp-compat
tramp-loaddefs trampver format-spec advice saveplace icomplete xref
savehist browse-url shell pcomplete warnings arc-mode archive-mode
ange-ftp socks network-stream nsm auth-source cl-macs cl-seq eieio
byte-opt gv bytecomp byte-compile cl-extra seq cconv eieio-core
cl-loaddefs pcase cl-lib gnus-util mm-util help-fns mail-prsvr
password-cache starttls tls dired cc-mode cc-fonts easymenu cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs comint
ansi-color ring calc-ext calc calc-loaddefs calc-macs time-stamp
time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
w32notify w32 multi-tty make-network-process emacs)

Memory information:
((conses 8 345101 52543)
 (symbols 32 43222 2)
 (miscs 32 278 1325)
 (strings 16 100168 21170)
 (string-bytes 1 2854256)
 (vectors 8 49499)
 (vector-slots 4 967355 64132)
 (floats 8 603 1334)
 (intervals 28 3770 1352)
 (buffers 516 36))

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[martin rudalics]

 > In buffer *scratch*:
 >
 >    (setq f (make-frame '((left . -1))))
 >    #<frame emacs <at> 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 right monitor):

I'm not familiar with multiple monitors.  But according to the Elisp
manual ...

`left'
      The position, in pixels, of the left (or right) edge of the frame
      with respect to the left (or right) edge of the screen.  The value
      may be:

     an integer
           A positive integer relates the left edge of the frame to the
           left edge of the screen.  A negative integer relates the
	                              ^^^^^^^^^^^^^^^^
           right frame edge to the right screen edge.

     `(+ POS)'
           This specifies the position of the left frame edge relative
           to the left screen edge.  The integer POS may be positive or
           negative; a negative value specifies a position outside the
           screen or on a monitor other than the primary one (for
           multi-monitor displays).

     `(- POS)'
           This specifies the position of the right frame edge relative
           to the right screen edge.  The integer POS may be positive or
           negative; a negative value specifies a position outside the
           screen or on a monitor other than the primary one (for
           multi-monitor displays).

... you try to the position the right edge of the frame by 1 pixel left
of the right edge of the "screen".  Didn't you get exactly that?  That
is, talking about a "left offset" in this case is misleading.  What was
your "right offset?

Simply disregard this message if you were aware of what you were doing.

martin

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[Francis Litterio]

martin rudalics <rudalics <at> gmx.at> writes:

>  > In buffer *scratch*:
>  >
>  >    (setq f (make-frame '((left . -1))))
>  >    #<frame emacs <at> IZSYSTEM023 015257f0>
>  >
>  >    (frame-parameter f 'left)
>  >    3155
>  >
>  > The left offset of the new frame appears to be 1920 pixels too
>  > far to the right.

> ... you try to the position the right edge of the frame by 1 pixel 
left
> of the right edge of the "screen".  Didn't you get exactly that?

No. The new frame is completely off-screen, almost a full monitor's
width right of the right edge of the the right monitor.  It's left
frame parameter has been computed incorrectly by function
x_calc_absolute_position.

> That
> is, talking about a "left offset" in this case is misleading.
> What was your "right offset?

An Emacs frame does not have a "right offset".  The (left . -1)
above means to set the left frame parameter to whatever value
is needed to position the right edge of the frame at the right
edge of the display.  That does not happen in my case,
because my display's left offsets start at -1980 (at the
left edge of the left monitor) and proceed to 0 (the left
edge of the right monitor) and then to +1979 (right edge of
the right monitor).

Function x_calc_absolute_position does not account for the fact
that my left monitor's left offsets are negative.  I believe that
is the root of the bug.
--
Fran
flitterio <at> gmail.com

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[martin rudalics]

 > Function x_calc_absolute_position does not account for the fact
 > that my left monitor's left offsets are negative.  I believe that
 > is the root of the bug.

If `display-monitor-attributes-list' returns the correct geometry values
it shouldn't be too hard to fix this.  That is, after the final
calculation of f->left_pos in x_calc_absolute_position subtract from it
the value (if negative) of whatever w32_display_monitor_attributes_list
returns as first value in `geometry' and from f->top_pos the second
value.  I can't test this here so it makes little sense to code it.

If you see the problem elsewhere too, we should probably postpone the
adjustment sketched above to my_set_window_pos in w32term.c.

martin

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[Francis Litterio]

martin rudalics <rudalics <at> gmx.at> writes:

> 
>  > Function x_calc_absolute_position does not account for the fact
>  > that my left monitor's left offsets are negative.  I believe that
>  > is the root of the bug.
> 
> If `display-monitor-attributes-list' returns the correct geometry 
values
> it shouldn't be too hard to fix this.

Thanks, Martin.  I see display-monitor-attributes-list return
this value:

  (((geometry 0 0 1920 1080)
    (workarea 0 0 1920 1080)
    (mm-size 677 381)
    (name . "\\\\.\\DISPLAY1")
    (frames #<frame emacs - Izsystem023 - *Buffer List* 06e2fad8>))
   ((geometry -1920 0 1920 1080)
    (workarea -1920 0 1920 1080)
    (mm-size 677 381)
    (name . "\\\\.\\DISPLAY2")
    (frames)))

Note the "-1920" in the info for DISPLAY2.  So I think all
the information is there to fix this.

> That is, after the final
> calculation of f->left_pos in x_calc_absolute_position subtract from 
it
> the value (if negative) of whatever 
w32_display_monitor_attributes_list
> returns as first value in `geometry' and from f->top_pos the second
> value.

I could do this in pure Elisp, but x_calc_absolute_position is
written in C, and I'm weak at using Elisp functions and objects
from C.  I'll give it a try and re-test.  If I get something
working, I'll post the patch here for review.
--
Fran

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[martin rudalics]

 > I could do this in pure Elisp, but x_calc_absolute_position is
 > written in C, and I'm weak at using Elisp functions and objects
 > from C.  I'll give it a try and re-test.  If I get something
 > working, I'll post the patch here for review.

Please do that.  Few people on this list seem to use multiple monitors
set-ups.

Thanks, martin

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[Andy Moreton]

On Mon 03 Aug 2015, martin rudalics wrote:

>> I could do this in pure Elisp, but x_calc_absolute_position is
>> written in C, and I'm weak at using Elisp functions and objects
>> from C.  I'll give it a try and re-test.  If I get something
>> working, I'll post the patch here for review.
>
> Please do that.  Few people on this list seem to use multiple monitors
> set-ups.
>
> Thanks, martin

I have a multi-monitor setup and can help test patches for this. As you
know the display code well, it would speed things up if you posted an
untested patch to illustrate how you think this should be solved.

    AndyM

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[Glenn Morris]

martin rudalics wrote:

>> I could do this in pure Elisp, but x_calc_absolute_position is
>> written in C, and I'm weak at using Elisp functions and objects
>> from C.  I'll give it a try and re-test.  If I get something
>> working, I'll post the patch here for review.
>
> Please do that.  Few people on this list seem to use multiple monitors
> set-ups.

BTW, if it's just the lack of two physical monitors that's stopping
anyone working on such things, note that you can simulate such a setup
in software. Eg something like

Xephyr +xinerama -screen 800x600 -origin 800,0 -screen 800x600 :1 &
DISPLAY=:1.0 gnome-session            # or whatever you prefer

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[Fran Litterio]

Glenn Morris <rgm <at> gnu.org> writes:

> BTW, if it's just the lack of two physical monitors that's stopping
> anyone working on such things, note that you can simulate such a setup
> in software. Eg something like
> 
> Xephyr +xinerama -screen 800x600 -origin 800,0 -screen 800x600 :1 &
> DISPLAY=:1.0 gnome-session            # or whatever you prefer

Interesting, thanks.  If frame 'left parameters are always
non-negative under X, then this problem only happens on Windows,
because the root cause is a failure to account for negative
'left values in certain monitor arrangements.

Does anyone with multiple monitors and X see negative 'left
parameters for frames on the leftmost monitor?
--
Fran
flitterio <at> gmail.com

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[Andy Moreton]

On Tue 04 Aug 2015, Fran Litterio wrote:

> Glenn Morris <rgm <at> gnu.org> writes:
>
>> BTW, if it's just the lack of two physical monitors that's stopping
>> anyone working on such things, note that you can simulate such a setup
>> in software. Eg something like
>> 
>> Xephyr +xinerama -screen 800x600 -origin 800,0 -screen 800x600 :1 &
>> DISPLAY=:1.0 gnome-session            # or whatever you prefer
>
> Interesting, thanks.  If frame 'left parameters are always
> non-negative under X, then this problem only happens on Windows,
> because the root cause is a failure to account for negative
> 'left values in certain monitor arrangements.
>
> Does anyone with multiple monitors and X see negative 'left
> parameters for frames on the leftmost monitor?

Yes. Arranging the monitors like this, so the desktop extends to both
monitors:

  +----------+
  |          |
  | DISPLAY2 |
  |          |+----------+
  +----------+|          |
              | DISPLAY1 |
              | (primary)|
              +----------+

  (display-monitor-attributes-list)
  ;; ==>
  '(((geometry 0 0 1920 1080)
     (workarea 0 0 1920 1050)
     (mm-size 677 381)
     (name . "\\\\.\\DISPLAY1")
     (frames ...))
    ((geometry -1680 -1050 1680 1050)
     (workarea -1680 -1050 1680 1050)
     (mm-size 593 370)
     (name . "\\\\.\\DISPLAY2")
     (frames ...)))

  ;; For a frame on DISPLAY2:
  (frame-parameter (window-frame) 'left) ;; ==>  (+ -1668)
  (frame-parameter (window-frame) 'top)  ;; ==>  (+ -1046)

The patch below fixes the problem for me on a Mingw64 build, and creates
frames at the correct position.  Please try it and report the results.

(Copyright papers are not yet on file, but I mailed them today).

diff --git a/src/w32term.c b/src/w32term.c
index 82b05bffffec..ac55c6f73d32 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -5931,16 +5931,48 @@ x_calc_absolute_position (struct frame *f)
       top_bottom_borders_height = 32;
     }
 
+  /* If the desktop extends to multiple monitors then monitors to
+     the left of (or above) the primary monitor may use negative
+     coordinates.  Find the X and Y offsets of the display origin.  */
+  int display_left = 0;
+  int display_top = 0;
+  if (flags & (XNegative | YNegative))
+    {
+      Lisp_Object list;
+
+      list = Fw32_display_monitor_attributes_list (FRAME_X_DISPLAY (f));
+      while (CONSP (list))
+        {
+          Lisp_Object attributes = CAR(list);
+          Lisp_Object geometry;
+          Lisp_Object monitor_left, monitor_top;
+
+          list = CDR(list);
+
+          geometry = Fassoc (Qgeometry, attributes);
+          if (!NILP (geometry))
+            {
+              monitor_left = Fnth (make_number (1), geometry);
+              monitor_top  = Fnth (make_number (2), geometry);
+
+              display_left = min (display_left, XINT (monitor_left));
+              display_top  = min (display_top,  XINT (monitor_top));
+            }
+        }
+    }
+
   /* Treat negative positions as relative to the rightmost bottommost
      position that fits on the screen.  */
   if (flags & XNegative)
     f->left_pos = (x_display_pixel_width (FRAME_DISPLAY_INFO (f))
+                   + display_left
 		   - FRAME_PIXEL_WIDTH (f)
 		   + f->left_pos
 		   - (left_right_borders_width - 1));
 
   if (flags & YNegative)
     f->top_pos = (x_display_pixel_height (FRAME_DISPLAY_INFO (f))
+                  + display_top
 		  - FRAME_PIXEL_HEIGHT (f)
 		  + f->top_pos
 		  - (top_bottom_borders_height - 1));

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[martin rudalics]

 > The patch below fixes the problem for me on a Mingw64 build, and creates
 > frames at the correct position.  Please try it and report the results.
 >
 > (Copyright papers are not yet on file, but I mailed them today).

Andy informed us that his copyright papers are now on file so we can
install this patch.

Francis, did you try the patch?  If not, pretty please do.

Also, did anyone see a similar problem on X or anywhere else?  I don't
use multiple monitors and am not eager to simluate them.

Thanks for responses, martin

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[Fran]

[-- Attachment #1: Type: text/plain, Size: 754 bytes --]

Hi Martin,

I'll try the patch today or tomorrow and report back. Sorry for the delay,
but a work deadline is looming.
--
Fran

On Tue, Oct 6, 2015 at 3:57 AM, martin rudalics <rudalics@gmx.at> wrote:

> > The patch below fixes the problem for me on a Mingw64 build, and creates
> > frames at the correct position.  Please try it and report the results.
> >
> > (Copyright papers are not yet on file, but I mailed them today).
>
> Andy informed us that his copyright papers are now on file so we can
> install this patch.
>
> Francis, did you try the patch?  If not, pretty please do.
>
> Also, did anyone see a similar problem on X or anywhere else?  I don't
> use multiple monitors and am not eager to simluate them.
>
> Thanks for responses, martin
>

[-- Attachment #2: Type: text/html, Size: 1149 bytes --]

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[Francis Litterio]

martin rudalics <rudalics <at> gmx.at> writes:

>  > The patch below fixes the problem for me on a Mingw64 build, and creates
>  > frames at the correct position.  Please try it and report the results.
> 
> Andy informed us that his copyright papers are now on file so we can
> install this patch.
> 
> Francis, did you try the patch?  If not, pretty please do.

This patch fixes the problem for me under Windows.  Many thanks to Andy
Moreton!  Since Andy reports that negative X offsets also happen under
the X Window system, should this also be fixed in function
x_calc_absolute_position in src/term.c?
--
Fran

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[Andy Moreton]

On Wed 21 Oct 2015, Francis Litterio wrote:

> martin rudalics <rudalics <at> gmx.at> writes:
>
>>  > The patch below fixes the problem for me on a Mingw64 build, and creates
>>  > frames at the correct position.  Please try it and report the results.
>> 
>> Andy informed us that his copyright papers are now on file so we can
>> install this patch.
>> 
>> Francis, did you try the patch?  If not, pretty please do.
>
> This patch fixes the problem for me under Windows.  Many thanks to Andy
> Moreton!  Since Andy reports that negative X offsets also happen under
> the X Window system, should this also be fixed in function
> x_calc_absolute_position in src/term.c?

I only reported that I also see negative cooredinates on MS Windows: I
don't know how X11 behaves (the patch was for Windows-specific code).

    AndyM

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[martin rudalics]

 > This patch fixes the problem for me under Windows.  Many thanks to Andy
 > Moreton!  Since Andy reports that negative X offsets also happen under
 > the X Window system, should this also be fixed in function
 > x_calc_absolute_position in src/term.c?

Thanks for testing, Francis.  AFAICT nobody reported a similar problem
on X so far.  So Andy please resend us your patch as attachment and
provide some suitable ChangeLog entry and I will install it (unless you
can already do that yourself).

Thanks, martin

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[Andy Moreton]

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

On Thu 22 Oct 2015, martin rudalics wrote:

>> This patch fixes the problem for me under Windows.  Many thanks to Andy
>> Moreton!  Since Andy reports that negative X offsets also happen under
>> the X Window system, should this also be fixed in function
>> x_calc_absolute_position in src/term.c?
>
> Thanks for testing, Francis.  AFAICT nobody reported a similar problem
> on X so far.  So Andy please resend us your patch as attachment and
> provide some suitable ChangeLog entry and I will install it (unless you
> can already do that yourself).
>
> Thanks, martin

Hopefully this reply includes a suiteably formatted patch.

    AndyM


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: multimon patch --]
[-- Type: text/x-patch, Size: 2273 bytes --]

From 7aa74f58b14061493dda5a23256eaf4e4af405c4 Mon Sep 17 00:00:00 2001
From: Andy Moreton <andrewjmoreton@gmail.com>
Date: Tue, 27 Oct 2015 21:47:06 +0000
Subject: [PATCH] Fix frame position with multiple monitors (Bug#21173)

* src/w32term.c (x_calc_absolute_position): Find display origin to
allow for negative coordinates.
---
 src/w32term.c | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/src/w32term.c b/src/w32term.c
index 831786726792..fb4135830708 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -5913,16 +5913,49 @@ x_calc_absolute_position (struct frame *f)
       top_bottom_borders_height = 32;
     }
 
+  /* With multiple monitors, we can legitimately get negative
+     coordinates (for monitors above or to the left of the primary
+     monitor).  Find the display origin to ensure negative positions
+     are computed correctly (Bug#21173).  */
+  int display_left = 0;
+  int display_top = 0;
+  if (flags & (XNegative | YNegative))
+    {
+      Lisp_Object list;
+
+      list = Fw32_display_monitor_attributes_list (FRAME_X_DISPLAY (f));
+      while (CONSP (list))
+        {
+          Lisp_Object attributes = CAR(list);
+          Lisp_Object geometry;
+          Lisp_Object monitor_left, monitor_top;
+
+          list = CDR(list);
+
+          geometry = Fassoc (Qgeometry, attributes);
+          if (!NILP (geometry))
+            {
+              monitor_left = Fnth (make_number (1), geometry);
+              monitor_top  = Fnth (make_number (2), geometry);
+
+              display_left = min (display_left, XINT (monitor_left));
+              display_top  = min (display_top,  XINT (monitor_top));
+            }
+        }
+    }
+
   /* Treat negative positions as relative to the rightmost bottommost
      position that fits on the screen.  */
   if (flags & XNegative)
     f->left_pos = (x_display_pixel_width (FRAME_DISPLAY_INFO (f))
+                   + display_left
 		   - FRAME_PIXEL_WIDTH (f)
 		   + f->left_pos
 		   - (left_right_borders_width - 1));
 
   if (flags & YNegative)
     f->top_pos = (x_display_pixel_height (FRAME_DISPLAY_INFO (f))
+                  + display_top
 		  - FRAME_PIXEL_HEIGHT (f)
 		  + f->top_pos
 		  - (top_bottom_borders_height - 1));
-- 
2.5.3

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[martin rudalics]

 > Hopefully this reply includes a suiteably formatted patch.

Thanks.  But compiling gets me now:

../../src/w32term.c: In function 'x_calc_absolute_position':
../../src/w32term.c:5926:7: error: incompatible type for argument 1 of 'Fw32_display_monitor_attributes_list'
./globals.h:4463:1: note: expected 'Lisp_Object' but argument is of type 'int'

I suppose you meant writing something like

       Lisp_Object frame, list;

       XSETFRAME (frame, f);
       list = Fw32_display_monitor_attributes_list (frame);

Please have a look.

Thanks, martin

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[Andy Moreton]

On Wed 28 Oct 2015, martin rudalics wrote:

>> Hopefully this reply includes a suiteably formatted patch.
>
> Thanks.  But compiling gets me now:
>
> ../../src/w32term.c: In function 'x_calc_absolute_position':
> ../../src/w32term.c:5926:7: error: incompatible type for argument 1 of 'Fw32_display_monitor_attributes_list'
> ./globals.h:4463:1: note: expected 'Lisp_Object' but argument is of type 'int'

What non-default build options are you using to see this error ?
I've built this without warnings on:
  mingw32 32bit
  mingw32 32bit wide-int
  mingw64 64bit
  cygwin  64bit 

> I suppose you meant writing something like
>
>       Lisp_Object frame, list;
>
>       XSETFRAME (frame, f);
>       list = Fw32_display_monitor_attributes_list (frame);
>
> Please have a look.

I'm sure you know more about it than me - I don't know enough about the
internals to judge which is correct. Feel free to adjust the patch to
fix this.

The patch as shown was tested with multiple monitors on Win7 64bit for both
mingw64 and cygwin w32 builds, and worked correctly with the testcase
from the original reporter.

I've retested this briefly with your fix, which still works for the
simple testcase shows by Fran Litterio.

    AndyM

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Wed, 28 Oct 2015 14:13:28 +0000
> 
> On Wed 28 Oct 2015, martin rudalics wrote:
> 
> >> Hopefully this reply includes a suiteably formatted patch.
> >
> > Thanks.  But compiling gets me now:
> >
> > ../../src/w32term.c: In function 'x_calc_absolute_position':
> > ../../src/w32term.c:5926:7: error: incompatible type for argument 1 of 'Fw32_display_monitor_attributes_list'
> > ./globals.h:4463:1: note: expected 'Lisp_Object' but argument is of type 'int'
> 
> What non-default build options are you using to see this error ?

I think the warnings depend on the version of GCC.

> I've built this without warnings on:
>   mingw32 32bit
>   mingw32 32bit wide-int
>   mingw64 64bit
>   cygwin  64bit 
> 
> > I suppose you meant writing something like
> >
> >       Lisp_Object frame, list;
> >
> >       XSETFRAME (frame, f);
> >       list = Fw32_display_monitor_attributes_list (frame);
> >
> > Please have a look.
> 
> I'm sure you know more about it than me - I don't know enough about the
> internals to judge which is correct. Feel free to adjust the patch to
> fix this.

Martin is right: Fw32_display_monitor_attributes_list accepts a
Lisp_Object as its argument, which should be either nil, a frame, a
terminal, or a display name (a string), whereas FRAME_X_DISPLAY
returns zero on MS-Windows.  I think it works for you because Qnil has
the value of zero.  To catch such problems, invoke the configure
script with the --enable-check-lisp-object-type switch.

> The patch as shown was tested with multiple monitors on Win7 64bit for both
> mingw64 and cygwin w32 builds, and worked correctly with the testcase
> from the original reporter.
> 
> I've retested this briefly with your fix, which still works for the
> simple testcase shows by Fran Litterio.

To see the difference, you need a test case where the selected frame
and the frame used in your code are different.

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[Andy Moreton]

On Wed 28 Oct 2015, Eli Zaretskii wrote:

>> From: Andy Moreton <andrewjmoreton@gmail.com>
>> Date: Wed, 28 Oct 2015 14:13:28 +0000
>> 
>> On Wed 28 Oct 2015, martin rudalics wrote:
>> > I suppose you meant writing something like
>> >
>> >       Lisp_Object frame, list;
>> >
>> >       XSETFRAME (frame, f);
>> >       list = Fw32_display_monitor_attributes_list (frame);
>> >
>> > Please have a look.
>> 
>> I'm sure you know more about it than me - I don't know enough about the
>> internals to judge which is correct. Feel free to adjust the patch to
>> fix this.
>
> Martin is right: Fw32_display_monitor_attributes_list accepts a
> Lisp_Object as its argument, which should be either nil, a frame, a
> terminal, or a display name (a string), whereas FRAME_X_DISPLAY
> returns zero on MS-Windows.  I think it works for you because Qnil has
> the value of zero.  To catch such problems, invoke the configure
> script with the --enable-check-lisp-object-type switch.

Thanks Eli - adding the configure switch reproduces the warning for me.

>> The patch as shown was tested with multiple monitors on Win7 64bit for both
>> mingw64 and cygwin w32 builds, and worked correctly with the testcase
>> from the original reporter.
>> 
>> I've retested this briefly with your fix, which still works for the
>> simple testcase shows by Fran Litterio.
>
> To see the difference, you need a test case where the selected frame
> and the frame used in your code are different.

Please suggest a suitable test case. The patch fixed the original bug,
and has not caused me any problems in daily usage.

    AndyM

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Wed, 28 Oct 2015 17:25:31 +0000
> 
> > To see the difference, you need a test case where the selected frame
> > and the frame used in your code are different.
> 
> Please suggest a suitable test case. The patch fixed the original bug,
> and has not caused me any problems in daily usage.

Indeed, I missed the fact that this code is only interested in the
"display", not the frame.  And the w32 build of Emacs only supports a
single display, so the frame indeed doesn't matter.  Which means you
could invoke Fw32_display_monitor_attributes_list with the argument of
Qnil, and still get the same effect.

Sorry for the noise.

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[martin rudalics]

 > What non-default build options are you using to see this error ?
 > I've built this without warnings on:
 >    mingw32 32bit
 >    mingw32 32bit wide-int
 >    mingw64 64bit
 >    cygwin  64bit

I use --enable-checking=yes and --enable-check-lisp-object-type=yes.

 >> I suppose you meant writing something like
 >>
 >>        Lisp_Object frame, list;
 >>
 >>        XSETFRAME (frame, f);
 >>        list = Fw32_display_monitor_attributes_list (frame);
 >>
 >> Please have a look.
 >
 > I'm sure you know more about it than me - I don't know enough about the
 > internals to judge which is correct. Feel free to adjust the patch to
 > fix this.
 >
 > The patch as shown was tested with multiple monitors on Win7 64bit for both
 > mingw64 and cygwin w32 builds, and worked correctly with the testcase
 > from the original reporter.
 >
 > I've retested this briefly with your fix, which still works for the
 > simple testcase shows by Fran Litterio.

Then please simply write

              list = Fw32_display_monitor_attributes_list (Qnil);

I can't safely change it because I can't test this.  If, as Eli says,
the value doesn't matter, then Qnil should be safe.

martin

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[Andy Moreton]

On Wed 28 Oct 2015, martin rudalics wrote:

>> What non-default build options are you using to see this error ?
>> I've built this without warnings on:
>>    mingw32 32bit
>>    mingw32 32bit wide-int
>>    mingw64 64bit
>>    cygwin  64bit
>
> I use --enable-checking=yes and --enable-check-lisp-object-type=yes.
>
>>> I suppose you meant writing something like
>>>
>>>        Lisp_Object frame, list;
>>>
>>>        XSETFRAME (frame, f);
>>>        list = Fw32_display_monitor_attributes_list (frame);
>>>
>>> Please have a look.
>>
>> I'm sure you know more about it than me - I don't know enough about the
>> internals to judge which is correct. Feel free to adjust the patch to
>> fix this.
>>
>> The patch as shown was tested with multiple monitors on Win7 64bit for both
>> mingw64 and cygwin w32 builds, and worked correctly with the testcase
>> from the original reporter.
>>
>> I've retested this briefly with your fix, which still works for the
>> simple testcase shows by Fran Litterio.
>
> Then please simply write
>
>              list = Fw32_display_monitor_attributes_list (Qnil);
>
> I can't safely change it because I can't test this.  If, as Eli says,
> the value doesn't matter, then Qnil should be safe.

I've tested with this change on mingw64 64bit and cygwin 64bit w32
builds, and both create frames at the correct position. Tested patch
with your change is below:

diff --git a/src/w32term.c b/src/w32term.c
index 831786726792..f764e250aa81 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -5913,16 +5913,49 @@ x_calc_absolute_position (struct frame *f)
       top_bottom_borders_height = 32;
     }
 
+  /* With multiple monitors, we can legitimately get negative
+     coordinates (for monitors above or to the left of the primary
+     monitor).  Find the display origin to ensure negative positions
+     are computed correctly (Bug#21173).  */
+  int display_left = 0;
+  int display_top = 0;
+  if (flags & (XNegative | YNegative))
+    {
+      Lisp_Object list;
+
+      list = Fw32_display_monitor_attributes_list (Qnil);
+      while (CONSP (list))
+        {
+          Lisp_Object attributes = CAR(list);
+          Lisp_Object geometry;
+          Lisp_Object monitor_left, monitor_top;
+
+          list = CDR(list);
+
+          geometry = Fassoc (Qgeometry, attributes);
+          if (!NILP (geometry))
+            {
+              monitor_left = Fnth (make_number (1), geometry);
+              monitor_top  = Fnth (make_number (2), geometry);
+
+              display_left = min (display_left, XINT (monitor_left));
+              display_top  = min (display_top,  XINT (monitor_top));
+            }
+        }
+    }
+
   /* Treat negative positions as relative to the rightmost bottommost
      position that fits on the screen.  */
   if (flags & XNegative)
     f->left_pos = (x_display_pixel_width (FRAME_DISPLAY_INFO (f))
+                   + display_left
 		   - FRAME_PIXEL_WIDTH (f)
 		   + f->left_pos
 		   - (left_right_borders_width - 1));
 
   if (flags & YNegative)
     f->top_pos = (x_display_pixel_height (FRAME_DISPLAY_INFO (f))
+                  + display_top
 		  - FRAME_PIXEL_HEIGHT (f)
 		  + f->top_pos
 		  - (top_bottom_borders_height - 1));

bug#21173: 25.0.50; New frames positioned off screen with multiple monitors

[martin rudalics]

 > I've tested with this change on mingw64 64bit and cygwin 64bit w32
 > builds, and both create frames at the correct position. Tested patch
 > with your change is below:

Pushed as

d7a67c5..dc95cb8  master -> master

Please close the bug if appropriate.

Thanks for the fix, martin