GNU bug report logs - #25818
25.2; frame moved off display does not return (OS X)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 25818 in the body.
You can then email your comments to 25818 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: charles <at> aurox.ch (Charles A. Roelli)
To: bug-gnu-emacs <at> gnu.org
Subject: 25.2; frame moved off display does not return (OS X)
Date: Mon, 20 Feb 2017 21:04:58 +0100

After looking into a possible bug in Ediff on OS X
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25057) it looks like
there may be a bug in the frame handling code for OS X.

You can evaluate this code from emacs -Q to have a frame gradually moved
in steps of 200 px from position ((top . 1) (left . 1)) until it's just
past the right edge of the display (more or less), and then come back
again:

(let ((display-width (display-pixel-width))
      (dx            200)
      (frame-x       1))
  (setq frame-test (make-frame
		    `((top . 1) (left . ,frame-x))))
  (sleep-for 0.5)
  ;; 1. Move it until it's off-screen.
  (while (< frame-x display-width)
    (setq frame-x (+ frame-x dx))
    (modify-frame-parameters frame-test
			     `((left . ,frame-x)))
    (sleep-for 0.5))
  (sleep-for 1)
  ;; 2. Bring it back.
  (while (> frame-x dx)
    (setq frame-x (- frame-x dx))
    (modify-frame-parameters frame-test
			     `((left . ,frame-x)))
    (sleep-for 0.5))
  (sleep-for 1)
  (delete-frame frame-test))

On GNU/Linux and MS Windows the frame behaves as expected: when the
frame parameters are changed to bring it back onscreen (step 2), the
frame becomes visible again.  On OS X 10.6 the frame stays off screen,
however, and I can't find any way to put it back on screen.  You can
change the frame parameters for `top' and `left', and they'll stick, but
they don't actually seem to have any effect.

Can someone reproduce this on a more recent OS X?  Maybe the problem is
fixed in newer versions.

In GNU Emacs 25.2.1 (x86_64-apple-darwin10.8.0, NS appkit-1038.36 Version 10.6.8 (Build 10K549))
 of 2017-02-07 built on gray
Windowing system distributor 'Apple', version 10.3.1038
Configured using:
 'configure --with-modules'

Configured features:
JPEG RSVG NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES

Message #8 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: "Charles A. Roelli" <charles <at> aurox.ch>, 25818 <at> debbugs.gnu.org
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS
 X)
Date: Thu, 23 Feb 2017 09:49:54 +0100

> You can evaluate this code from emacs -Q to have a frame gradually moved
> in steps of 200 px from position ((top . 1) (left . 1)) until it's just
> past the right edge of the display (more or less), and then come back
> again:
...
> On GNU/Linux and MS Windows the frame behaves as expected: when the
> frame parameters are changed to bring it back onscreen (step 2), the
> frame becomes visible again.  On OS X 10.6 the frame stays off screen,
> however, and I can't find any way to put it back on screen.  You can
> change the frame parameters for `top' and `left', and they'll stick, but
> they don't actually seem to have any effect.
>
> Can someone reproduce this on a more recent OS X?  Maybe the problem is
> fixed in newer versions.

FWIW this seems OS X specific behavior.  Compare

http://superuser.com/questions/55341/move-an-off-screen-window-back-on-screen-on-mac-os-x

http://osxdaily.com/2013/08/14/move-window-back-on-screen-mac-os-x/

http://www.gottabemobile.com/how-to-move-an-os-x-window-thats-stuck-off-screen/

http://apple.stackexchange.com/questions/709/how-to-retrieve-windows-that-have-moved-off-screen

https://www.cnet.com/forums/discussions/bring-misplaced-off-screen-applications-back-to-your-desktop-380285/

martin

Message #11 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: charles <at> aurox.ch (Charles A. Roelli)
To: martin rudalics <rudalics <at> gmx.at>
Cc: 25818 <at> debbugs.gnu.org
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Sun, 26 Feb 2017 12:26:46 +0100

See also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=18801.  It's
possible that the problem was introduced from 24.3 to 24.4.

Message #14 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: charles <at> aurox.ch (Charles A. Roelli)
To: martin rudalics <rudalics <at> gmx.at>
Cc: 25818 <at> debbugs.gnu.org
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Sun, 26 Feb 2017 16:40:04 +0100

On Sun, Feb 26 2017 at 12:26:46 pm, Charles A. Roelli wrote:

> See also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=18801.  It's
> possible that the problem was introduced from 24.3 to 24.4.

I built 24.3 and 24.4 from source, and it is correct that a regression
with Emacs' handling of the window system in OS X happened between those
two releases.

The form I suggested to show the issue,

(let ((display-width (display-pixel-width))
      (dx            200)
      (frame-x       1))
  (setq frame-test (make-frame
		    `((top . 1) (left . ,frame-x))))
  (sleep-for 0.5)
  ;; 1. Move it until it's off-screen.
  (while (< frame-x display-width)
    (setq frame-x (+ frame-x dx))
    (modify-frame-parameters frame-test
			     `((left . ,frame-x)))
    (sleep-for 0.5))
  (sleep-for 1)
  ;; 2. Bring it back.
  (while (> frame-x dx)
    (setq frame-x (- frame-x dx))
    (modify-frame-parameters frame-test
			     `((left . ,frame-x)))
    (sleep-for 0.5))
  (sleep-for 1)
  (delete-frame frame-test))

works correctly on 24.3 but not on 24.4 (24.4 has the same behavior as
25.1 and 25.2, detailed in my first message).  I guess the regression
would be in src/nsterm.m, or maybe src/nsfns.m.

Message #17 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: "Charles A. Roelli" <charles <at> aurox.ch>
Cc: 25818 <at> debbugs.gnu.org
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS
 X)
Date: Sun, 26 Feb 2017 17:45:40 +0100

>> See also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=18801.  It's
>> possible that the problem was introduced from 24.3 to 24.4.
>
> I built 24.3 and 24.4 from source, and it is correct that a regression
> with Emacs' handling of the window system in OS X happened between those
> two releases.
>
> The form I suggested to show the issue,
[...]
> works correctly on 24.3 but not on 24.4 (24.4 has the same behavior as
> 25.1 and 25.2, detailed in my first message).  I guess the regression
> would be in src/nsterm.m, or maybe src/nsfns.m.

So something seems to have happened that Emacs fell into the same trap
as other applications (which, in my understanding, is that the frame
gets displayed on another, probably non-existent, monitor).  I'm afraid
that my only suggestion is to bisect the sources until you've found the
culprit.

(I suppose you verified that the value returned by ‘display-pixel-width’
is the same in 24.3 and 24.4.)

martin

Message #20 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: charles <at> aurox.ch (Charles A. Roelli)
To: martin rudalics <rudalics <at> gmx.at>
Cc: 25818 <at> debbugs.gnu.org
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Sun, 26 Feb 2017 20:42:37 +0100

On Sun, Feb 26 2017 at 05:45:40 pm, martin rudalics wrote:

>>> See also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=18801.  It's
>>> possible that the problem was introduced from 24.3 to 24.4.
>>
>> I built 24.3 and 24.4 from source, and it is correct that a regression
>> with Emacs' handling of the window system in OS X happened between those
>> two releases.
>>
>> The form I suggested to show the issue,
> [...]
>> works correctly on 24.3 but not on 24.4 (24.4 has the same behavior as
>> 25.1 and 25.2, detailed in my first message).  I guess the regression
>> would be in src/nsterm.m, or maybe src/nsfns.m.
>
> So something seems to have happened that Emacs fell into the same trap
> as other applications (which, in my understanding, is that the frame
> gets displayed on another, probably non-existent, monitor).  I'm afraid
> that my only suggestion is to bisect the sources until you've found the
> culprit.
>
> (I suppose you verified that the value returned by ‘display-pixel-width’
> is the same in 24.3 and 24.4.)

No, I did not; thanks for the reminder.  In 24.3, with a second monitor
plugged in, (display-pixel-width) returns 1280, i.e. the width only of
my primary monitor.  In 24.4, in the same situation,
(display-pixel-width) returns 2330 = (+ 1280 1050).  Second monitor is
1050 pixels wide.

In both the case of 24.3 and 24.4 with no external monitor attached,
(display-pixel-width) returns 1280.

So it seems that the code for `display-pixel-width' (or code that it
calls) was changed between those releases, maybe to support multiple
monitors.

I notice now that when running the test form on 24.3, the created frame
never actually leaves the visible portion of the screen.  For example,
when the code calls (sleep-for 1) with the frame supposedly being
offscreen according to its frame parameters (right before step 2), the
frame is in reality maybe 50 pixels left of the screen's right edge.
This is with just one monitor.  When I run the example with two
monitors, the frame just spills into the second monitor but does not go
further (since 24.3 does not seem to give correct values for
`display-pixel-width' with multiple monitors).

So it seems like there used to be code in Emacs that prevented a frame
from programmatically leaving the screen area in OS X.  For example, in
24.3, if I call (modify-frame-parameters nil '((left . 10000))), the
frame is put, as above, about 50 pixels left of the screen's right edge.

Message #23 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: "Charles A. Roelli" <charles <at> aurox.ch>
Cc: 25818 <at> debbugs.gnu.org, YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS
 X)
Date: Mon, 27 Feb 2017 09:05:14 +0100

> No, I did not; thanks for the reminder.  In 24.3, with a second monitor
> plugged in, (display-pixel-width) returns 1280, i.e. the width only of
> my primary monitor.  In 24.4, in the same situation,
> (display-pixel-width) returns 2330 = (+ 1280 1050).  Second monitor is
> 1050 pixels wide.

So the problem occurs only with the second monitor plugged in?

> In both the case of 24.3 and 24.4 with no external monitor attached,
> (display-pixel-width) returns 1280.

And there is no problem in this case with 24.4?

> So it seems that the code for `display-pixel-width' (or code that it
> calls) was changed between those releases, maybe to support multiple
> monitors.

The code was changed in two tranches

2013-05-20  YAMAMOTO Mitsuharu  <mituharu <at> math.s.chiba-u.ac.jp>

2013-07-04  YAMAMOTO Mitsuharu  <mituharu <at> math.s.chiba-u.ac.jp>

I'll CC him - maybe he can help us solving this issue in a more general
way.

> I notice now that when running the test form on 24.3, the created frame
> never actually leaves the visible portion of the screen.  For example,
> when the code calls (sleep-for 1) with the frame supposedly being
> offscreen according to its frame parameters (right before step 2), the
> frame is in reality maybe 50 pixels left of the screen's right edge.
> This is with just one monitor.  When I run the example with two
> monitors, the frame just spills into the second monitor but does not go
> further (since 24.3 does not seem to give correct values for
> `display-pixel-width' with multiple monitors).

Do you mean that the value is already wrong for the primary monitor or
that the value simply does not account for the second monitor?

> So it seems like there used to be code in Emacs that prevented a frame
> from programmatically leaving the screen area in OS X.  For example, in
> 24.3, if I call (modify-frame-parameters nil '((left . 10000))), the
> frame is put, as above, about 50 pixels left of the screen's right edge.

In any case we have to change ediff-wind.el in order to fix the issue at
hand.

martin

Message #26 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: charles <at> aurox.ch (Charles A. Roelli)
To: martin rudalics <rudalics <at> gmx.at>
Cc: 25818 <at> debbugs.gnu.org, YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Mon, 27 Feb 2017 11:34:20 +0100

On Mon, Feb 27 2017 at 09:05:14 am, martin rudalics wrote:

>> No, I did not; thanks for the reminder.  In 24.3, with a second monitor
>> plugged in, (display-pixel-width) returns 1280, i.e. the width only of
>> my primary monitor.  In 24.4, in the same situation,
>> (display-pixel-width) returns 2330 = (+ 1280 1050).  Second monitor is
>> 1050 pixels wide.
>
> So the problem occurs only with the second monitor plugged in?

The problem occurs (in 24.4) regardless of how many monitors are plugged
in, and it may not be directly related to `display-pixel-width'.

>
>> In both the case of 24.3 and 24.4 with no external monitor attached,
>> (display-pixel-width) returns 1280.
>
> And there is no problem in this case with 24.4?

No, as above, the problem always occurs with 24.4, regardless of the
number of monitors connected.

>
>> So it seems that the code for `display-pixel-width' (or code that it
>> calls) was changed between those releases, maybe to support multiple
>> monitors.
>
> The code was changed in two tranches
>
> 2013-05-20  YAMAMOTO Mitsuharu  <mituharu <at> math.s.chiba-u.ac.jp>
>
> 2013-07-04  YAMAMOTO Mitsuharu  <mituharu <at> math.s.chiba-u.ac.jp>
>
> I'll CC him - maybe he can help us solving this issue in a more general
> way.

Thanks.

>
>> I notice now that when running the test form on 24.3, the created frame
>> never actually leaves the visible portion of the screen.  For example,
>> when the code calls (sleep-for 1) with the frame supposedly being
>> offscreen according to its frame parameters (right before step 2), the
>> frame is in reality maybe 50 pixels left of the screen's right edge.
>> This is with just one monitor.  When I run the example with two
>> monitors, the frame just spills into the second monitor but does not go
>> further (since 24.3 does not seem to give correct values for
>> `display-pixel-width' with multiple monitors).
>
> Do you mean that the value is already wrong for the primary monitor or
> that the value simply does not account for the second monitor?

The value does not account for the second monitor (but is correct for
the primary monitor).  This is the behavior that was fixed in 24.4.

>> So it seems like there used to be code in Emacs that prevented a frame
>> from programmatically leaving the screen area in OS X.  For example, in
>> 24.3, if I call (modify-frame-parameters nil '((left . 10000))), the
>> frame is put, as above, about 50 pixels left of the screen's right edge.
>
> In any case we have to change ediff-wind.el in order to fix the issue at
> hand.

We could, but it would be better to restore Emacs 24.3's behavior in OS
X, where frames are effectively prevented from moving off-screen.  There
is no point in allowing a frame to be moved off-screen, IIUC, since the
frame seems to never reappear no matter what we do with it.

>
>
> martin

Message #29 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: charles <at> aurox.ch (Charles A. Roelli)
To: martin rudalics <rudalics <at> gmx.at>
Cc: 25818 <at> debbugs.gnu.org, andlind <at> gmail.com,
 YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Mon, 27 Feb 2017 21:47:41 +0100

[Message part 1 (text/plain, inline)]

Bisecting between emacs-24.3 and emacs-24.4 led me to commit
680e6b8c5a28489733df544edb074fd29d0522a0, which introduces the
regression.  There is also a possibly related commit two hours later,
1269a680862a9bc6cd65e3d26ef05f68c7521632.

Commit 680e6b8c introduces the behavior observed in 24.4, where a frame
is not constrained to the screen area.  Also interesting is that
`display-pixel-width' works correctly (for multiple monitors as well,
that is) in the commit and the commits immediately preceding it, so it
may only be tangentially related.

I'm attaching the changeset of 680e6b8c and CCing the author.

I looked into constrainFrameRect, and it seems to have different
behavior depending on whether "Spaces" are available (introduced in OS X
10.9 apparently).  Might also have something to with the issue at hand.

[680e6b8c-2013-12-19-frame-handling.diff (text/x-patch, attachment)]

Message #32 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: charles <at> aurox.ch (Charles A. Roelli)
To: martin rudalics <rudalics <at> gmx.at>
Cc: 25818 <at> debbugs.gnu.org, jan.h.d <at> swipnet.se,
 YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>, andlind <at> gmail.com
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Tue, 28 Feb 2017 11:12:27 +0100

[Message part 1 (text/plain, inline)]

The attached patch against master fixes the issue on OS X 10.6 by
constraining frames to the visible area.  Behavior with OS X 10.9+ (and
"Spaces") still needs testing.  The patch also fixes
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=14713, which has
reappeared since it was fixed (at least it has reappeared on 10.6).

Also CCing Jan Djärv who worked on this area of the code previously (see
e61a31bf999b37f32616e5159196d179657ad788).

[0001-nsterm.m-constrainFrameRect-toScreen-Constrain-frame.patch (text/x-patch, attachment)]

Message #35 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: Anders Lindgren <andlind <at> gmail.com>
To: "Charles A. Roelli" <charles <at> aurox.ch>
Cc: martin rudalics <rudalics <at> gmx.at>,
 YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>, 25818 <at> debbugs.gnu.org
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Tue, 28 Feb 2017 14:20:55 +0100

[Message part 1 (text/plain, inline)]

Hi!

I'm the author behind the changes you are discussing.

Emacs 24.3 demonstrates a number of problems when you want to stretch Emacs
across two screens and also when placing the title bar above the top of the
screen (which is very useful when `ns-auto-hide-menu-bar' is non-nil).
Applying the suggested patch would only reintroduce those problems.

A better solution would be to add to code to check if the Emacs frame is
outside any monitor, and then (and only then) call the constrainFrameRect
method of the parent class.

Also, if I remember correctly, 24.3 behaved differently when you had one
monitor compared to multiple monitors. I removed this, as I didn't see the
point of it, and because if introduced an extra level of complexity when it
came to testing.

When it comes to `display-pixel-width', it should return the combined width
of side-by-side monitors, so 24.4 and newer Emacs versions behave correctly.

I have attached a test file I used when I worked with the NS port.

Anyway, I'm glad that you have looked into this. The number of people
actively working on the NS port are close to zero (I threw in the towel
about a year ago, simply because I couldn't find the time I needed to spend
on it). If you are interested in contributing, you can look at the
"NeXTstep port" section of the "TODO" file.

    -- Anders


On Mon, Feb 27, 2017 at 9:47 PM, Charles A. Roelli <charles <at> aurox.ch> wrote:

> Bisecting between emacs-24.3 and emacs-24.4 led me to commit
> 680e6b8c5a28489733df544edb074fd29d0522a0, which introduces the
> regression.  There is also a possibly related commit two hours later,
> 1269a680862a9bc6cd65e3d26ef05f68c7521632.
>
> Commit 680e6b8c introduces the behavior observed in 24.4, where a frame
> is not constrained to the screen area.  Also interesting is that
> `display-pixel-width' works correctly (for multiple monitors as well,
> that is) in the commit and the commits immediately preceding it, so it
> may only be tangentially related.
>
> I'm attaching the changeset of 680e6b8c and CCing the author.
>
> I looked into constrainFrameRect, and it seems to have different
> behavior depending on whether "Spaces" are available (introduced in OS X
> 10.9 apparently).  Might also have something to with the issue at hand.
>
>

[Message part 2 (text/html, inline)]

[ns-frame-test.el (application/octet-stream, attachment)]

Message #38 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: charles <at> aurox.ch (Charles A. Roelli)
To: Anders Lindgren <andlind <at> gmail.com>
Cc: martin rudalics <rudalics <at> gmx.at>,
 YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>, 25818 <at> debbugs.gnu.org
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Tue, 28 Feb 2017 16:05:09 +0100

Thanks for the quick response.

On Tue, Feb 28 2017 at 02:20:55 pm, Anders Lindgren wrote:

> Hi!
>
> I'm the author behind the changes you are discussing.
>
> Emacs 24.3 demonstrates a number of problems when you want to stretch Emacs
> across two screens and also when placing the title bar above the top of the
> screen (which is very useful when `ns-auto-hide-menu-bar' is non-nil).
> Applying the suggested patch would only reintroduce those problems.

I've tested my patched version of Emacs master and I can stretch one
frame across both screens (seemingly) without any problem.  It is
possible that my patched version would not do the right thing on OS X
10.9+, though, if the interaction with "Spaces" and constrainFrameRect
is different there.

[BTW, if I understand right, "Spaces" in Mac OS X 10.9+ prevent you from
having any frame spanning multiple monitors.  Does the current Emacs
code (without my patch) remove that limitation?]

Also, thank you for pointing out `ns-auto-hide-menu-bar'.  I did not
know about that variable.  But I do not understand why you would want to
place a frame above the top of the screen when the menu bar is hidden.
It might give you an extra row of text, at the cost of obscuring the
close/iconify/maximize buttons, and the frame title.  You could get more
bang for your buck by turning off `tool-bar-mode', IMO.  And I don't
think OS X natively allows a user to place a frame above the top of the
screen anyway.

> A better solution would be to add to code to check if the Emacs frame is
> outside any monitor, and then (and only then) call the constrainFrameRect
> method of the parent class.

Your use case above for a frame (placing it above the top of the screen,
as with `(set-frame-position (selected-frame) 0 -10)' in your test
code), would (I think) count as bringing the frame outside of a screen,
and therefore constrainFrameRect would kick in, bringing the frame back
to ((top . 0) (left . 0)) -- as my patched version does.  But this is
apparently not what you want.  So we would need to allow some leeway in
the calculation to allow a frame to be only slightly outside of a
monitor?  This sounds complicated to me.

> Also, if I remember correctly, 24.3 behaved differently when you had one
> monitor compared to multiple monitors. I removed this, as I didn't see the
> point of it, and because if introduced an extra level of complexity when it
> came to testing.

In my recently built emacs-24.3, I can't see any different behavior with
a second monitor (except, of course, that `display-pixel-width' only
accounts for the first monitor, which must ultimately have some
consequences).

> When it comes to `display-pixel-width', it should return the combined width
> of side-by-side monitors, so 24.4 and newer Emacs versions behave correctly.
>
> I have attached a test file I used when I worked with the NS port.

Thank you, it's a good start for testing out the frame handling code on
different versions.

> Anyway, I'm glad that you have looked into this. The number of people
> actively working on the NS port are close to zero (I threw in the towel
> about a year ago, simply because I couldn't find the time I needed to spend
> on it). If you are interested in contributing, you can look at the
> "NeXTstep port" section of the "TODO" file.

Will do.  Do you know of any good resources for tinkering in this area?
I have some old Apple docsets available which I haven't really gotten
around to reading yet, but that's about it.

>
> On Mon, Feb 27, 2017 at 9:47 PM, Charles A. Roelli <charles <at> aurox.ch> wrote:
>
>> Bisecting between emacs-24.3 and emacs-24.4 led me to commit
>> 680e6b8c5a28489733df544edb074fd29d0522a0, which introduces the
>> regression.  There is also a possibly related commit two hours later,
>> 1269a680862a9bc6cd65e3d26ef05f68c7521632.
>>
>> Commit 680e6b8c introduces the behavior observed in 24.4, where a frame
>> is not constrained to the screen area.  Also interesting is that
>> `display-pixel-width' works correctly (for multiple monitors as well,
>> that is) in the commit and the commits immediately preceding it, so it
>> may only be tangentially related.
>>
>> I'm attaching the changeset of 680e6b8c and CCing the author.
>>
>> I looked into constrainFrameRect, and it seems to have different
>> behavior depending on whether "Spaces" are available (introduced in OS X
>> 10.9 apparently).  Might also have something to with the issue at hand.

Message #41 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: Anders Lindgren <andlind <at> gmail.com>
To: "Charles A. Roelli" <charles <at> aurox.ch>
Cc: martin rudalics <rudalics <at> gmx.at>,
 YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>, 25818 <at> debbugs.gnu.org
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Tue, 28 Feb 2017 21:35:15 +0100

[Message part 1 (text/plain, inline)]

Hi!


> I've tested my patched version of Emacs master and I can stretch one
> frame across both screens (seemingly) without any problem.  It is
> possible that my patched version would not do the right thing on OS X
> 10.9+, though, if the interaction with "Spaces" and constrainFrameRect
> is different there.
>
> [BTW, if I understand right, "Spaces" in Mac OS X 10.9+ prevent you from
> having any frame spanning multiple monitors.  Does the current Emacs
> code (without my patch) remove that limitation?]
>

In 10.9, a "space" is a dedicated full-frame area. I don't think your patch
will affect this.

It took quite a lot of work to get the current implementation to work for a
variety of scenarios. To throw in a "quick fix" for another scenario will
most likely break things that work today. It would be better to identify
some situations when the function should behave differently and fix those
specific cases.


> A better solution would be to add to code to check if the Emacs frame is
> > outside any monitor, and then (and only then) call the constrainFrameRect
> > method of the parent class.
>
> Your use case above for a frame (placing it above the top of the screen,
> as with `(set-frame-position (selected-frame) 0 -10)' in your test
> code), would (I think) count as bringing the frame outside of a screen,
> and therefore constrainFrameRect would kick in, bringing the frame back
> to ((top . 0) (left . 0)) -- as my patched version does.  But this is
> apparently not what you want.  So we would need to allow some leeway in
> the calculation to allow a frame to be only slightly outside of a
> monitor?  This sounds complicated to me.
>

I think it is acceptable if a frame is partially outside the display. What
I suggested was to check if the frame was ENTIRELY outside any monitor, and
in that case call the parent function to bring it in. This test should be
trivial to implement.

You can find a lot of the recent design decisions of the NS port in the
epic discussion thread of bug 21415.


Also, thank you for pointing out `ns-auto-hide-menu-bar'.  I did not
> know about that variable.  But I do not understand why you would want to
> place a frame above the top of the screen when the menu bar is hidden.
> It might give you an extra row of text, at the cost of obscuring the
> close/iconify/maximize buttons, and the frame title.  You could get more
> bang for your buck by turning off `tool-bar-mode', IMO.  And I don't
> think OS X natively allows a user to place a frame above the top of the
> screen anyway.
>

By placing the title bar above the top of the screen, I'm able to use the
entire height of the monitor for text, while having access to the menu by
moving the mouse pointer to the top of the screen. I don't need the buttons
and the frame title is of little use.

Admittedly, I'm a bit crazy when it comes to screen real estate -- with a
small font, six side-by-side windows, and Follow mode enabled, I get 888
consecutive lines of text.


> Anyway, I'm glad that you have looked into this. The number of people
> > actively working on the NS port are close to zero (I threw in the towel
> > about a year ago, simply because I couldn't find the time I needed to
> spend
> > on it). If you are interested in contributing, you can look at the
> > "NeXTstep port" section of the "TODO" file.
>
> Will do.  Do you know of any good resources for tinkering in this area?
> I have some old Apple docsets available which I haven't really gotten
> around to reading yet, but that's about it.


I mostly look at the reference documentation like
https://developer.apple.com/reference/appkit/nswindow

There are tons of introductory text on macOS (which, internally, is similar
for iOS). You have to look for one which suit your background knowledge.
You can, however, skip anything related to the "Interface Builder", since
it's not used by Emacs. If you don't know Objective-C, I would recommend
you to start with an introduction to that, and go from there.

    -- Anders

[Message part 2 (text/html, inline)]

Message #44 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Anders Lindgren <andlind <at> gmail.com>, "Charles A. Roelli" <charles <at> aurox.ch>
Cc: 25818 <at> debbugs.gnu.org
Subject: RE: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Tue, 28 Feb 2017 14:05:26 -0800 (PST)

Excuse me for chiming in without really following this
thread.  I don't use OS X, for one thing, and I'm not
following this particular bug.

But if one of the questions is whether an Emacs user
(or code) should _be able_ to position a frame off
screen then I emphatically say yes, s?he should.

I have code that lets you incrementally move a frame
up/down/left/right, including wraparound or including
the possibility of not wrapping but continuing till
the frame is entirely off screen.

I don't see anything wrong with _allowing_ someone
to position a frame off screen.  Why they might want
to do that is up to them.

If that question is not in fact being raised in this
bug discussion, then please ignore this intrusion,
and sorry for the noise.

Message #47 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: Anders Lindgren <andlind <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 25818 <at> debbugs.gnu.org, "Charles A. Roelli" <charles <at> aurox.ch>
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Wed, 1 Mar 2017 11:48:24 +0100

[Message part 1 (text/plain, inline)]

Hi!

On Tue, Feb 28, 2017 at 11:05 PM, Drew Adams <drew.adams <at> oracle.com> wrote:

> But if one of the questions is whether an Emacs user
> (or code) should _be able_ to position a frame off
> screen then I emphatically say yes, s?he should.
>
> I have code that lets you incrementally move a frame
> up/down/left/right, including wraparound or including
> the possibility of not wrapping but continuing till
> the frame is entirely off screen.
>
> I don't see anything wrong with _allowing_ someone
> to position a frame off screen.  Why they might want
> to do that is up to them.
>

I can see the point of your argument. After all, this is how Emacs work
today, and most people have been fine with it.

However, I don't feel 100% comfortable with the current situation.

The main issue is people with laptops connected to an extern monitor. When
the external monitor is disconnected, Emacs might land off screen. I would
imagine that most people would prefer that Emacs would be moved and resized
to fit in the screen of the laptop (as I imagine, most macOS application
behave).

Secondly, I miss an easy accessible method to move off-screen frames into
the visible parts of the display. On macOS, the menu is always accessible
even if the window isn't, so the obvious place would be a menu item like
"Collect Frame" (I noticed that "C-x 5 c" is unbound) -- it could be placed
after "Delete Frame" in the "File" menu.


If that question is not in fact being raised in this
> bug discussion, then please ignore this intrusion,
> and sorry for the noise.
>

No need to apologize, your input is always welcome!

    -- Anders

[Message part 2 (text/html, inline)]

Message #50 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: 25818 <at> debbugs.gnu.org, "Charles A. Roelli" <charles <at> aurox.ch>
Subject: RE: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Wed, 1 Mar 2017 08:10:35 -0800 (PST)

> I can see the point of your argument. After all, this is how Emacs
> work today, and most people have been fine with it.
> 
> However, I don't feel 100% comfortable with the current situation.
> 
> The main issue is people with laptops connected to an extern monitor.
> When the external monitor is disconnected, Emacs might land off screen.
> I would imagine that most people would prefer that Emacs would be
> moved and resized to fit in the screen of the laptop (as I imagine,
> most macOS application behave).

> Secondly, I miss an easy accessible method to move off-screen frames
> into the visible parts of the display. On macOS, the menu is always
> accessible even if the window isn't, so the obvious place would be
> a menu item like "Collect Frame" (I noticed that "C-x 5 c" is unbound)
> -- it could be placed after "Delete Frame" in the "File" menu.

I think I agree with everything you wrote.

Users & Emacs-Lisp code should be able to position a frame partially
or fully off-screen.

But users should have simple ways to bring a given frame or all
frames that are completely off screen on screen.

And I agree with Martin's observation that such things should be
available from Emacs, but when a window mgr does something we don't
want wrt positioning users (and Emacs code) should be able to try
to compensate in some way (change the position to something that is
acceptable by the window mgr).  And our doc should make clear to
users that Emacs doesn't get the last word, so that some behavior
they see may be imposed by the window mgr, i.e., beyond Emacs's
control.

Message #53 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: charles <at> aurox.ch (Charles A. Roelli)
To: Anders Lindgren <andlind <at> gmail.com>
Cc: 25818 <at> debbugs.gnu.org, YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>,
 martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Sun, 19 Mar 2017 20:38:50 +0100

Hi again,

Sorry for taking a while to get back on this.

Looking at this issue again, it would be helpful to know what version of
OS X you use and whether you see the issue that I described in the first
message of this thread (*), and also whether the patch I suggested stops
frames from being placed above the top of the screen.  Because from what
I can see, I don't see how the patch will prevent you from doing so,
unless you have "Spaces" turned off.

(*) One quick way of finding out is running something like
    `(set-frame-position (selected-frame) 0 10000)' (best done from
    `emacs -Q').  If the moved frame cannot be returned on-screen
    programmatically, then you have the issue.  If it stays on-screen,
    then you don't.

My patch got rid of these lines:

-#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_9
-  // If separate spaces is on, it is like each screen is independent.  There is
-  // no spanning of frames across screens.
-  if ([NSScreen screensHaveSeparateSpaces])
-    {
-      NSTRACE_MSG ("Screens have separate spaces");
-      frameRect = [super constrainFrameRect:frameRect toScreen:screen];
-      NSTRACE_RETURN_RECT (frameRect);
-      return frameRect;
-    }
-#endif

According to the Apple documentation, screensHaveSeparateSpaces()
"returns a Boolean value that indicates whether each screen can have its
own set of spaces.  This method reflects whether the “Displays have
separate Spaces” option is enabled in Mission Control system
preference. You might use the return value to determine how to present
your app when in fullscreen mode."

So the idea of this code was to constrain a frame only if "Spaces" is
enabled, right?  I assume then, that if you have "Spaces" turned on (but
even if you don't necessarily use the feature), then frames are
prevented from going entirely off-screen (which is a must for OS X).

The reason I ask this is because I have no idea whether the problem
exists in Emacs on newer versions of OS X.  If it doesn't, then the fix
can be added only for OS X < 10.9.

Message #56 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: Anders Lindgren <andlind <at> gmail.com>
To: "Charles A. Roelli" <charles <at> aurox.ch>
Cc: 25818 <at> debbugs.gnu.org, YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>,
 martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Mon, 27 Mar 2017 20:22:00 +0200

[Message part 1 (text/plain, inline)]

Hi!

Sorry for not getting back to you immediately.

Anyway, I did try your original patch. Unfortunately, the effect is as I
anticipated. When the patch is applied, if a frame is placed slightly
outside the display area, it will be moved back inside the borders.
Effectively, this means that you can't place the title bar above the top of
the display, which is possible (by design) with an unpatched Emacs. (By the
way, this is possible in Emacs on Windows as well.)

I use OS X 10.10.5 (Yosemite). I have "spaces" disabled, which allows an
Emacs frame to be stretched across multiple monitors.

To solve your problem, and to ensure that we don't break anything for my
use case, we would need to call "[super constrainFrameRect:frameRect
toScreen:screen];" only when the frame is determined to be fully outside
any monitor. This is not rocket science -- just iterate over all monitors
and check that the frame overlap at least one.

Sincerely,
    Anders Lindgren

On Sun, Mar 19, 2017 at 8:38 PM, Charles A. Roelli <charles <at> aurox.ch> wrote:

> Hi again,
>
> Sorry for taking a while to get back on this.
>
> Looking at this issue again, it would be helpful to know what version of
> OS X you use and whether you see the issue that I described in the first
> message of this thread (*), and also whether the patch I suggested stops
> frames from being placed above the top of the screen.  Because from what
> I can see, I don't see how the patch will prevent you from doing so,
> unless you have "Spaces" turned off.
>
> (*) One quick way of finding out is running something like
>     `(set-frame-position (selected-frame) 0 10000)' (best done from
>     `emacs -Q').  If the moved frame cannot be returned on-screen
>     programmatically, then you have the issue.  If it stays on-screen,
>     then you don't.
>
> My patch got rid of these lines:
>
> -#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_9
> -  // If separate spaces is on, it is like each screen is independent.
> There is
> -  // no spanning of frames across screens.
> -  if ([NSScreen screensHaveSeparateSpaces])
> -    {
> -      NSTRACE_MSG ("Screens have separate spaces");
> -      frameRect = [super constrainFrameRect:frameRect toScreen:screen];
> -      NSTRACE_RETURN_RECT (frameRect);
> -      return frameRect;
> -    }
> -#endif
>
> According to the Apple documentation, screensHaveSeparateSpaces()
> "returns a Boolean value that indicates whether each screen can have its
> own set of spaces.  This method reflects whether the “Displays have
> separate Spaces” option is enabled in Mission Control system
> preference. You might use the return value to determine how to present
> your app when in fullscreen mode."
>
> So the idea of this code was to constrain a frame only if "Spaces" is
> enabled, right?  I assume then, that if you have "Spaces" turned on (but
> even if you don't necessarily use the feature), then frames are
> prevented from going entirely off-screen (which is a must for OS X).
>
> The reason I ask this is because I have no idea whether the problem
> exists in Emacs on newer versions of OS X.  If it doesn't, then the fix
> can be added only for OS X < 10.9.
>

[Message part 2 (text/html, inline)]

Message #59 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: charles <at> aurox.ch (Charles A. Roelli)
To: Anders Lindgren <andlind <at> gmail.com>
Cc: 25818 <at> debbugs.gnu.org, YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>,
 martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Sun, 02 Apr 2017 16:14:29 +0200

[Message part 1 (text/plain, inline)]

Hi Anders,

Does the attached patch work for you?  It's still a bit rough around the
edges, but seems to do the right thing.

A quick test on 10.6:

(setq ns-auto-hide-menu-bar t)

;; Places the frame just above the top of the screen.
(set-frame-position (selected-frame) 0 -20)

;; Frame would be completely offscreen; so it's constrained and brought
;; back.
(set-frame-position (selected-frame) 0 -10000)

Cheers,
Charles

[0001-Constrain-frames-to-visible-area-of-screens-in-OS-X.patch (text/x-patch, attachment)]

Message #62 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: Anders Lindgren <andlind <at> gmail.com>
To: "Charles A. Roelli" <charles <at> aurox.ch>
Cc: 25818 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Mon, 3 Apr 2017 10:33:04 +0200

[Message part 1 (text/plain, inline)]

Hi!

I think this is a good start. However, there is a case that your patch
miss. If you have multiple monitors arranged in, say, an L-shape, a frame
might be placed inside "multiscreenRect", without actually being visible on
any screen. (This typically occur when you have a large desktop monitor
connected to a laptop or when you have one monitor placed horizontally and
one vertically.)

Fortunately, it should be easy to fix. What about something like (in
pseudo-code):

     BOOL in_any_screen = NO;
     for (screen = /* Loop over all screens */ ...)
       {
         if (overlapping(frame, scree))
           {
              in_any_screen = YES;
              break;
           }
        }
     if ( ! in_any_screen )
       {
         /* Move the frame in */
       }

Anyway, I think that we're on the right track and I appreciate that you
have taken time to work on this!

    -- Anders

PS. I just found another, unrelated, problem, when comparing the NS and X11
versions. When passing a negative value to `set-frame-position' it is
supposed to place the frame relative to the right/bottom border of the
display, but in the NS version it doesn't. (The X11 version gets the Y
placement wrong with 48 pixels, but that is another story.)

On Sun, Apr 2, 2017 at 4:14 PM, Charles A. Roelli <charles <at> aurox.ch> wrote:

> Hi Anders,
>
> Does the attached patch work for you?  It's still a bit rough around the
> edges, but seems to do the right thing.
>
> A quick test on 10.6:
>
> (setq ns-auto-hide-menu-bar t)
>
> ;; Places the frame just above the top of the screen.
> (set-frame-position (selected-frame) 0 -20)
>
> ;; Frame would be completely offscreen; so it's constrained and brought
> ;; back.
> (set-frame-position (selected-frame) 0 -10000)
>
> Cheers,
> Charles
>
>

[Message part 2 (text/html, inline)]

Message #65 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: charles <at> aurox.ch (Charles A. Roelli)
To: Anders Lindgren <andlind <at> gmail.com>
Cc: 25818 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Sat, 08 Apr 2017 22:40:31 +0200

[Message part 1 (text/plain, inline)]

Hi Anders,

Following your idea, here's an updated patch that works equivalently.
Please let me know what you think.

> Anyway, I think that we're on the right track and I appreciate that you
> have taken time to work on this!

My pleasure!

> PS. I just found another, unrelated, problem, when comparing the NS and X11
> versions. When passing a negative value to `set-frame-position' it is
> supposed to place the frame relative to the right/bottom border of the
> display, but in the NS version it doesn't. (The X11 version gets the Y
> placement wrong with 48 pixels, but that is another story.)

Hm... but what if a second display is in the negative coordinate space?
How would you place a frame on it programmatically?  In any case I'll
try to build the X11 version and see how it does it -- I wasn't aware
that it still works on Mac OS.

Cheers,
Charles

>> A quick test on 10.6:
>>
>> (setq ns-auto-hide-menu-bar t)
>>
>> ;; Places the frame just above the top of the screen.
>> (set-frame-position (selected-frame) 0 -20)
>>
>> ;; Frame would be completely offscreen; so it's constrained and brought
>> ;; back.
>> (set-frame-position (selected-frame) 0 -10000)

[0001-Constrain-frames-to-visible-area-of-screens-in-OS-X-revised.patch (text/x-patch, attachment)]

Message #68 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: Anders Lindgren <andlind <at> gmail.com>
To: "Charles A. Roelli" <charles <at> aurox.ch>
Cc: 25818 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Sun, 9 Apr 2017 21:13:08 +0200

[Message part 1 (text/plain, inline)]

Hi!


> Following your idea, here's an updated patch that works equivalently.
> Please let me know what you think.
>

It looks really good! I've applied it and it works for my use case (placing
the menu bar above the top of the screen) and also for your (the frame
isn't visible at all). Also, I'm sure it will work with L-shaped layouts as
well, even though I haven't tried it.

I've got two minor comments. And when I say "minor" they really are minor,
feel free to disregard them if you like:

* The nsterm.m file is (almost) tab free, so I would appreciate if you
would untabify the code.

* Replace the comment with something like the following:

    // Check that the proposed frame placement is visible in at least
    // one screen.  If it is not, ask the system to reposition it.

If someone doesn't understand what the code does and why, the original
comment doesn't help as it only repeats the algorithm of the code. Also, I
don't see the need to refer to a bug number in the comment, except under
very special circumstances -- that information is available in the git
commit message.


> PS. I just found another, unrelated, problem, when comparing the NS and
> X11
> > versions. When passing a negative value to `set-frame-position' it is
> > supposed to place the frame relative to the right/bottom border of the
> > display, but in the NS version it doesn't. (The X11 version gets the Y
> > placement wrong with 48 pixels, but that is another story.)
>
> Hm... but what if a second display is in the negative coordinate space?
> How would you place a frame on it programmatically?


You can set the `left' and `top' frame parameters. If they are assigned an
integer they act like `set-frame-position' is supposed to work. However, if
they are assigned `(+ INTEGER)' or `(- INTEGER)' the value is specified
relative to the left (top) or right (bottom) edge of the display,
respectively. This allows a frame to be placed anywhere.


In any case I'll
> try to build the X11 version and see how it does it -- I wasn't aware
> that it still works on Mac OS.
>

It does. I've been using it as "the" reference implementation, whenever the
documentation isn't 100% clear.

    -- Anders

Cheers,
> Charles
>
> >> A quick test on 10.6:
> >>
> >> (setq ns-auto-hide-menu-bar t)
> >>
> >> ;; Places the frame just above the top of the screen.
> >> (set-frame-position (selected-frame) 0 -20)
> >>
> >> ;; Frame would be completely offscreen; so it's constrained and brought
> >> ;; back.
> >> (set-frame-position (selected-frame) 0 -10000)
>
>

[Message part 2 (text/html, inline)]

Message #71 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: charles <at> aurox.ch (Charles A. Roelli)
To: Anders Lindgren <andlind <at> gmail.com>
Cc: 25818 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Mon, 10 Apr 2017 21:54:48 +0200

[Message part 1 (text/plain, inline)]

Hi Anders,

> Also, I'm sure it will work with L-shaped layouts as well,
> even though I haven't tried it.

I gave it a try and it worked as expected.

> I've got two minor comments. And when I say "minor" they really are minor,
> feel free to disregard them if you like:
>
> * The nsterm.m file is (almost) tab free, so I would appreciate if you
> would untabify the code.
>
> * Replace the comment with something like the following:
>
>     // Check that the proposed frame placement is visible in at least
>     // one screen.  If it is not, ask the system to reposition it.
>
> If someone doesn't understand what the code does and why, the original
> comment doesn't help as it only repeats the algorithm of the code. Also, I
> don't see the need to refer to a bug number in the comment, except under
> very special circumstances -- that information is available in the git
> commit message.

Good points, I've made these fixes in the attached patch.

>> Hm... but what if a second display is in the negative coordinate space?
>> How would you place a frame on it programmatically?
>
> You can set the `left' and `top' frame parameters. If they are assigned an
> integer they act like `set-frame-position' is supposed to work. However, if
> they are assigned `(+ INTEGER)' or `(- INTEGER)' the value is specified
> relative to the left (top) or right (bottom) edge of the display,
> respectively. This allows a frame to be placed anywhere.

I see now, thanks for this explanation.  I tried building Emacs with X
(--with-x --with-ns=no) and the configuring step picked up my installed
version of GTK3, then later failed at the linking stage for temacs due
to some GDK-related symbols not being present.  Have you seen similar
errors?

Cheers,
Charles

[0001-Constrain-frames-to-visible-area-of-screens-in-OS-X-v2.patch (text/x-patch, attachment)]

Message #74 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: Anders Lindgren <andlind <at> gmail.com>
To: "Charles A. Roelli" <charles <at> aurox.ch>
Cc: 25818 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Tue, 11 Apr 2017 20:35:32 +0200

[Message part 1 (text/plain, inline)]

Hi!

On Mon, Apr 10, 2017 at 9:54 PM, Charles A. Roelli <charles <at> aurox.ch> wrote:

> Good points, I've made these fixes in the attached patch.
>

Looks good!

Have you assigned copyright to FSF?

Have you commit rights to the Emacs archive? If not, would you like me to
commit it for you?


I tried building Emacs with X
> (--with-x --with-ns=no) and the configuring step picked up my installed
> version of GTK3, then later failed at the linking stage for temacs due
> to some GDK-related symbols not being present.  Have you seen similar
> errors?
>

I haven't got GTK3 libraries installed. I've used the following command
line to configure:

./configure --with-x --with-ns=no --without-dbus --with-jpeg=no
--with-gif=no --with-tiff=no
--x-includes=/Developer/SDKs/MacOSX10.6.sdk/usr/X11/include/:/Developer/SDKs/MacOSX10.6.sdk/usr/X11/include/freetype2

    -- Anders

[Message part 2 (text/html, inline)]

Message #77 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: "Charles A. Roelli" <charles <at> aurox.ch>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: 25818 <at> debbugs.gnu.org, alan <at> idiocy.org, martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Thu, 27 Apr 2017 21:14:05 +0200

[Message part 1 (text/plain, inline)]

Hi Anders,

As discussed off-list, the copyright assignment is done.

I fixed the patch so that child frames are never constrained (after some 
testing, it seems that a child frame cannot get stuck off screen as long 
as its parent is still visible).  To test this out, evaluate the 
following from emacs -Q,

(progn
  (setq test-frame (make-frame `((parent-frame . ,(selected-frame)))))
  (set-frame-position test-frame 0 500))

and drag the parent frame down until its child is off screen. When the 
parent is moved back up, the child should reappear with it.  (Assuming 
Spaces is off; not sure what would happen in OS X 10.9+ in this case 
when Spaces is on... I guess the child would be constrained before it is 
placed off screen?).

I've also CC'ed Alan since this change is related to the new frame 
parameters.

Cheers,

Charles

[0001-Constrain-non-child-frames-to-screen-area-in-OS-X.patch (text/x-patch, attachment)]

Message #80 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: "Charles A. Roelli" <charles <at> aurox.ch>
Cc: 25818 <at> debbugs.gnu.org, Anders Lindgren <andlind <at> gmail.com>,
 martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Thu, 27 Apr 2017 21:05:23 +0100

On Thu, Apr 27, 2017 at 09:14:05PM +0200, Charles A. Roelli wrote:
> I fixed the patch so that child frames are never constrained (after some
> testing, it seems that a child frame cannot get stuck off screen as long as
> its parent is still visible).

Looks good to me. It doesn’t actually apply here, so I did it
manually. I suspect it just needs rebased onto a more recent commit or
something.

> and drag the parent frame down until its child is off screen. When the
> parent is moved back up, the child should reappear with it.

If you put the top of the child frame off the top of the screen, then
click on it, it jumps back down so the titlebar is visible again. Is
this intentional?

> * src/nsterm.m (constrainFrameRect:toScreen:): Constrain non-child
> frames in OS X, if they would otherwise go offscreen.

I can’t find this in CONTRIBUTE, but you’re allowed to specify
#ifdef’d code with something like:

* src/nsterm.m (constrainFrameRect:toScreen:) [NS_IMPL_COCOA]:
Constrain non-child frames if they would otherwise go offscreen.

Thanks for working on this. :)
-- 
Alan Third

Message #83 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: "Charles A. Roelli" <charles <at> aurox.ch>
To: Alan Third <alan <at> idiocy.org>
Cc: 25818 <at> debbugs.gnu.org, Anders Lindgren <andlind <at> gmail.com>,
 martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Fri, 28 Apr 2017 19:33:00 +0200

[Message part 1 (text/plain, inline)]

On 27/04/2017 22:05, Alan Third wrote:
> Looks good to me. It doesn’t actually apply here, so I did it
> manually. I suspect it just needs rebased onto a more recent commit or
> something.
You're right: attached is the rebased version.
>> and drag the parent frame down until its child is off screen. When the
>> parent is moved back up, the child should reappear with it.
> If you put the top of the child frame off the top of the screen, then
> click on it, it jumps back down so the titlebar is visible again. Is
> this intentional?
For me, this can be prevented by setting variable 
`ns-auto-hide-menu-bar' to t.  And on OS X 10.9+, the behavior may 
change if you have Spaces enabled (I haven't tested it).
>> * src/nsterm.m (constrainFrameRect:toScreen:): Constrain non-child
>> frames in OS X, if they would otherwise go offscreen.
> I can’t find this in CONTRIBUTE, but you’re allowed to specify
> #ifdef’d code with something like:
>
> * src/nsterm.m (constrainFrameRect:toScreen:) [NS_IMPL_COCOA]:
> Constrain non-child frames if they would otherwise go offscreen.
>
> Thanks for working on this. :)
My pleasure, and thank you for your work on the NS port.

[0001-Constrain-non-child-frames-to-screen-area-in-OS-X.patch (text/x-patch, attachment)]

Message #86 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: "Charles A. Roelli" <charles <at> aurox.ch>, 
 Anders Lindgren <andlind <at> gmail.com>
Cc: 25818 <at> debbugs.gnu.org, alan <at> idiocy.org
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS
 X)
Date: Sat, 29 Apr 2017 12:30:13 +0200

> I fixed the patch so that child frames are never constrained (after
> some testing, it seems that a child frame cannot get stuck off screen
> as long as its parent is still visible).  To test this out, evaluate
> the following from emacs -Q,
>
> (progn
>    (setq test-frame (make-frame `((parent-frame . ,(selected-frame)))))
>    (set-frame-position test-frame 0 500))
>
> and drag the parent frame down until its child is off screen.

Does this mean that the child frame does _not_ move together with its
parent frame?  That would constitute a major deviation from the other
platforms.

martin

Message #89 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: "Charles A. Roelli" <charles <at> aurox.ch>
To: martin rudalics <rudalics <at> gmx.at>, Anders Lindgren <andlind <at> gmail.com>
Cc: 25818 <at> debbugs.gnu.org, alan <at> idiocy.org
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Sat, 29 Apr 2017 13:15:10 +0200

With the current master branch, a child frame might be constrained on OS 
X 10.9+ with the "Spaces" windowing feature turned on, meaning that a 
child frame could be forced back into the screen area -- so yes, there 
could be a case where a child frame doesn't move together with its 
parent.  Maybe that will have to be fixed too; I'm on 10.6 though so I 
can't test.

Otherwise, though, when child/parent frames are not brought off screen, 
a child frame always moves with its parent.

My updated patch takes into account the case where "Spaces" is off or 
unavailable -- if you read the part above what I added:

#ifdef NS_IMPL_COCOA
#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_9
  // If separate spaces is on, it is like each screen is independent.  
There is
  // no spanning of frames across screens.
  if ([NSScreen screensHaveSeparateSpaces])
    {
      NSTRACE_MSG ("Screens have separate spaces");
      frameRect = [super constrainFrameRect:frameRect toScreen:screen];
      NSTRACE_RETURN_RECT (frameRect);
      return frameRect;
    }
#endif

there is nothing there to prevent a child frame from being constrained 
-- so I will need input from somebody else on that.


On 29/04/2017 12:30, martin rudalics wrote:
> > I fixed the patch so that child frames are never constrained (after
> > some testing, it seems that a child frame cannot get stuck off screen
> > as long as its parent is still visible).  To test this out, evaluate
> > the following from emacs -Q,
> >
> > (progn
> >    (setq test-frame (make-frame `((parent-frame . ,(selected-frame)))))
> >    (set-frame-position test-frame 0 500))
> >
> > and drag the parent frame down until its child is off screen.
>
> Does this mean that the child frame does _not_ move together with its
> parent frame?  That would constitute a major deviation from the other
> platforms.
>
> martin

Message #92 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: "Charles A. Roelli" <charles <at> aurox.ch>
Cc: martin rudalics <rudalics <at> gmx.at>, Anders Lindgren <andlind <at> gmail.com>,
 25818 <at> debbugs.gnu.org
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Sat, 29 Apr 2017 15:51:11 +0100

On Sat, Apr 29, 2017 at 01:15:10PM +0200, Charles A. Roelli wrote:
> My updated patch takes into account the case where "Spaces" is off or
> unavailable -- if you read the part above what I added:
> 
> #ifdef NS_IMPL_COCOA
> #if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_9
>   // If separate spaces is on, it is like each screen is independent.  There
> is
>   // no spanning of frames across screens.
>   if ([NSScreen screensHaveSeparateSpaces])
>     {
>       NSTRACE_MSG ("Screens have separate spaces");
>       frameRect = [super constrainFrameRect:frameRect toScreen:screen];
>       NSTRACE_RETURN_RECT (frameRect);
>       return frameRect;
>     }
> #endif
> 
> there is nothing there to prevent a child frame from being constrained -- so
> I will need input from somebody else on that.

I think the screensHaveSeparateSpaces setting makes each monitor a
completely independent screen, so you won’t run into the problems you
have in the normal set‐up where a frame might span two monitors.

Therefore I think we could just add a check for whether it’s a child
frame, and if so, don’t constrain it at all.

-- 
Alan Third

Message #95 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: Anders Lindgren <andlind <at> gmail.com>
To: "Charles A. Roelli" <charles <at> aurox.ch>
Cc: martin rudalics <rudalics <at> gmx.at>, Alan Third <alan <at> idiocy.org>,
 25818 <at> debbugs.gnu.org
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Sat, 29 Apr 2017 19:23:14 +0200

[Message part 1 (text/plain, inline)]

Hi!

If I understand correctly, when the menu bar is visible, macOS will force
any window down below it. It's not something one can do about it, as far as
I know.

However, when the menu bar is hidden, or on secondary monitors (i.e. one
that don't have a menu bar), a window can be placed above the top
programmatically (but it's not possible for a user to drag it there).

The reason the Emacs code checks if spaces are enabled is historical. The
original NS code in Emacs 23 didn't support stretching a frame across two
monitors (whereas Emacs 22 supported this). When this was fixed for Emacs
23 the maintainer of the time, Jan Djärv, decided to retain the original
behaviour when spaces are enabled (since a frame can't be stretched across
multiple monitors). Maybe this is something we could revisit now. (One
thing I'm curious about is if it is possible to hide the menu bar and place
the frame above the top of the display, if spaces are enabled -- I suspect
that it's not possible but I haven't tested.)

    -- Anders

On Sat, Apr 29, 2017 at 1:15 PM, Charles A. Roelli <charles <at> aurox.ch> wrote:

> With the current master branch, a child frame might be constrained on OS X
> 10.9+ with the "Spaces" windowing feature turned on, meaning that a child
> frame could be forced back into the screen area -- so yes, there could be a
> case where a child frame doesn't move together with its parent.  Maybe that
> will have to be fixed too; I'm on 10.6 though so I can't test.
>
> Otherwise, though, when child/parent frames are not brought off screen, a
> child frame always moves with its parent.
>
> My updated patch takes into account the case where "Spaces" is off or
> unavailable -- if you read the part above what I added:
>
> #ifdef NS_IMPL_COCOA
> #if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_9
>   // If separate spaces is on, it is like each screen is independent.
> There is
>   // no spanning of frames across screens.
>   if ([NSScreen screensHaveSeparateSpaces])
>     {
>       NSTRACE_MSG ("Screens have separate spaces");
>       frameRect = [super constrainFrameRect:frameRect toScreen:screen];
>       NSTRACE_RETURN_RECT (frameRect);
>       return frameRect;
>     }
> #endif
>
> there is nothing there to prevent a child frame from being constrained --
> so I will need input from somebody else on that.
>
>
>
> On 29/04/2017 12:30, martin rudalics wrote:
>
>> > I fixed the patch so that child frames are never constrained (after
>> > some testing, it seems that a child frame cannot get stuck off screen
>> > as long as its parent is still visible).  To test this out, evaluate
>> > the following from emacs -Q,
>> >
>> > (progn
>> >    (setq test-frame (make-frame `((parent-frame . ,(selected-frame)))))
>> >    (set-frame-position test-frame 0 500))
>> >
>> > and drag the parent frame down until its child is off screen.
>>
>> Does this mean that the child frame does _not_ move together with its
>> parent frame?  That would constitute a major deviation from the other
>> platforms.
>>
>> martin
>>
>
>

[Message part 2 (text/html, inline)]

Message #98 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: "Charles A. Roelli" <charles <at> aurox.ch>, 
 Anders Lindgren <andlind <at> gmail.com>
Cc: 25818 <at> debbugs.gnu.org, alan <at> idiocy.org
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS
 X)
Date: Sun, 30 Apr 2017 10:32:27 +0200

> Otherwise, though, when child/parent frames are not brought off
> screen, a child frame always moves with its parent.

Thanks for this clarification, martin

Message #101 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: "Charles A. Roelli" <charles <at> aurox.ch>
Cc: 25818 <at> debbugs.gnu.org, Anders Lindgren <andlind <at> gmail.com>,
 martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Tue, 2 May 2017 21:33:34 +0100

On Fri, Apr 28, 2017 at 07:33:00PM +0200, Charles A. Roelli wrote:
> On 27/04/2017 22:05, Alan Third wrote:
> > Looks good to me. It doesn’t actually apply here, so I did it
> > manually. I suspect it just needs rebased onto a more recent commit or
> > something.
> You're right: attached is the rebased version.

I’ve pushed this up to master.

Should I close this bug report, or do we want to look into the case
where screens have individual spaces?
-- 
Alan Third

Message #104 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: "Charles A. Roelli" <charles <at> aurox.ch>
To: Alan Third <alan <at> idiocy.org>
Cc: 25818 <at> debbugs.gnu.org, Anders Lindgren <andlind <at> gmail.com>,
 martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Fri, 5 May 2017 20:30:26 +0200

I'm ok with closing.  The behavior with "Spaces" turned on seems 
reasonable at the moment, and if there's any indication that child 
frames do get constrained as a result of it, we can fix that.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.