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