bug#26816: mouse movement support for OS X

[Alan Third <alan@idiocy.org>]

On Thu, May 11, 2017 at 08:06:13PM +0200, Charles A. Roelli wrote:
> > Presumably (frame-position) returns nonsensical values on your
> > portrait monitor, and (set-frame-position nil 0 0) also plants the
> > frame in the wrong place (ie. not the top left)?
> 
> (set-frame-position nil 0 0) places the frame in the top-left corner of the
> primary monitor for me in Emacs 25.2.  (frame-position) with the frame in
> the top-left corner of the secondary monitor reports (-1050 . -880).
> 
> I'm not sure: is this expected behavior?

It’s what I’d expect with the below modification to
NS_PARENT_WINDOW_TOP_POS, so if Emacs 25 does that too then I’m happy.

I was thinking that without the modification, Emacs 26 would do
strange things, just like it did with positioning the mouse pointer.

> I made the line say [[[NSScreen screens] objectAtIndex: 0]
> frame].size.height (equivalent to what you wrote) and the mouse can
> now be set to a position in the frame as expected. Thanks for your
> help with this.

Thank you for working on it. Besides, I introduced this particular
bug.

> This now reminds me of a related problem, though: with Emacs 25.2 (or in
> Emacs 26, with the above change applied to NS_PARENT_WINDOW_TOP_POS(f)),
> tooltips originating from an area with a help-echo property (like "Lisp
> Interaction" in the mode line in emacs -Q) in a frame on the secondary
> monitor actually show up in the primary monitor instead -- as if the tooltip
> frame is constrained to having a positive x-coordinate only.  I haven't
> found where it happens, but I guess the cause is similar.

Look at compute_tip_xy in nsfns.m. It moves tooltips into the positive
screen space. I’ve not managed to get to grips with this code yet.

I think what we want is for it to try to keep the tooltip on one
screen, so it’s not spanning two monitors, but allow it to go into
negative space.

Perhaps this should be a separate bug report.
-- 
Alan Third