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

[Charles A. Roelli]

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")))