GNU bug report logs - #26905
25.2: MacOS: tooltips show in wrong display

Previous Next

Package: emacs;

Reported by: "Charles A. Roelli" <charles <at> aurox.ch>

Date: Sat, 13 May 2017 07:44:02 UTC

Severity: normal

Found in version 25.2

Done: Alan Third <alan <at> idiocy.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: "Charles A. Roelli" <charles <at> aurox.ch>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 26905 <at> debbugs.gnu.org
Subject: bug#26905: 25.2: MacOS: tooltips show in wrong display
Date: Sat, 13 May 2017 16:04:32 +0200
FWIW, I found this change to the Windows port of Emacs (not sure if it 
was ever committed):


https://lists.gnu.org/archive/html/bug-gnu-emacs/2007-07/msg00153.html


And a more recent change as a result of #22549: commit 
c77ffc8019bceb850a794c13f2e3ad991cc7e412, with changes to xfns.c.


c77ffc8..: Oscar Fuentes 2016-02-06 Use monitor's resolution for 
positioning tooltips
  commit c77ffc8019bceb850a794c13f2e3ad991cc7e412
  Author: Oscar Fuentes <ofv <at> wanadoo.es>
  Date:   Sat Feb 6 22:12:53 2016 +0100

  Use monitor's resolution for positioning tooltips

  * src/xfns.c (compute_tip_xy): Use the resolution of the monitor where
  the mouse pointer is to avoid placing the tooltip over the border of
  the monitor on multi-head displays. Fixes bug#22549.


Seems like the Windows and X versions nowadays have a check that looks 
like this:

  else if (*root_x + XINT (dx) <= min_x)
    *root_x = 0; /* Can happen for negative dx */

i.e. compare *root_x + XINT (dx) against the variable "min_x", rather 
than comparing against zero, as is done in the NS port. Since frames can 
be in the negative coordinate space, it makes sense to allow a tooltip 
to have a x-coordinate less than 0 -- so the NS port's code should 
probably be changed.


I'm also not sure why, in the above code from the Windows and X 
versions, *root_x is constrained to zero if *root_x + dx goes below 
min_x.  Wouldn't it make more sense to constrain to min_x, which could 
be negative?


On 13/05/2017 11:56, Eli Zaretskii wrote:
>> From: "Charles A. Roelli" <charles <at> aurox.ch>
>> Date: Sat, 13 May 2017 11:02:04 +0200
>>
>> If I remove the marked lines in compute_tip_xy:
>>
>>       if (INTEGERP (left) || INTEGERP (right))
>>         *root_x = pt.x;
>> =>  else if (pt.x + XINT (dx) <= 0)
>> =>    *root_x = 0; /* Can happen for negative dx */
>>       else if (pt.x + XINT (dx) + width
>> 	     <= x_display_pixel_width (FRAME_DISPLAY_INFO (f)))
>>         /* It fits to the right of the pointer.  */
>>         *root_x = pt.x + XINT (dx);
>>       else if (width + XINT (dx) <= pt.x)
>>         /* It fits to the left of the pointer.  */
>>         *root_x = pt.x - width - XINT (dx);
>>       else
>>         /* Put it left justified on the screen -- it ought to fit that way.  */
>>         *root_x = 0;
>>
>> Then the problem is gone.
> Those lines were added to fix some problems (whose particulars I
> cannot find at the moment), so we shouldn't remove them without
> understanding what is going on.





This bug report was last modified 8 years and 2 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.