bug#26816: mouse movement support for OS X

[Charles A. Roelli]

Attached is a patch now working with multiple monitors.  I also added 
`ns-set-mouse-absolute-pixel-position', a test and a NEWS entry.  The 
test works interactively, but it requires a frame to run and I'm not 
sure whether tests run with them by default.

The code for handling the y-coord in 
`ns-set-mouse-absolute-pixel-position' is from 
`ns-display-monitor-attributes-list' (in the calculation of the screen 
geometry).  I also made (set-mouse-absolute-pixel-position 0 0) put the 
mouse in the top-left corner of the current screen.

I tried out both `set-mouse-position' and 
`set-mouse-absolute-pixel-position' on setups with the secondary monitor 
on the left, right, top and bottom, and they seem to work right.

I also got rid of the call to `ns_raise_frame' in 
`frame_set_mouse_pixel_position', which is unnecessary.

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

Done (#26905).

0001-mouse-movement-macos.patch
Description: Text Data