bug#25818: 25.2; frame moved off display does not return (OS X)

[Charles A. Roelli]

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@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.