bug#26905: 25.2: MacOS: tooltips show in wrong display

["Charles A. Roelli" <charles@aurox.ch>]

Continuing from bug#26816 
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26816#32):

On 11/05/2017 23:43, Alan Third wrote:

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

"Primary" and "secondary" monitors are as follows:

(display-monitor-attributes-list) =>

(((name . "Color LCD")
   (geometry 0 0 1280 800)
   (workarea 0 22 1280 714)
   (mm-size 290 180)
   (frames #<frame emacs-devel 0x105044260> #<frame *Backtrace* 
0x1199eca10> #<frame *vc-diff* 0x117dc82b8> #<frame nsterm.m 
0x121c49ad8> #<frame *shell* 0x119adf830> #<frame  *Minibuf-1* 0x119b33030>)
   (source . "NS"))
  ((name . "DELL 2007WFP")
   (geometry -1050 -880 1050 1680)
   (workarea -1050 -880 1050 1680)
   (mm-size 430 270)
   (frames #<frame nsterm.h 0x117c83fd0>)
   (source . "NS")))