Re: tooltip can be displayed outside the screen

Re: tooltip can be displayed outside the screen

[Richard M. Stallman]

    From: Tetsuo Tsukamoto <czkmt@remus.dti.ne.jp>
    To: emacs-pretest-bug@gnu.org

    I have just noticed tooltip can misplace itself and be shown
    partly/entirely outside the X window system screen, especially
    when Emacs frame is placed near the edge of the screen.

Could you explain what "outside the X window system screen" means?

For one thing, if the tooltip is outside the screen, how can you see
it?  In what sense "is" it anywhere?  (And where is it?)

The image seems to show just a little of a screen.
I am not sure what that means, but maybe I can guess.

Do you mean that the tootip appears _partly_ off the edge of the screen?

If that is the problem, could someone please look at it?

Re: tooltip can be displayed outside the screen

[Tetsuo Tsukamoto]

>>>>>   [Sat, 26 Nov 2005 22:28:04 -0500]
>>>>>   "Richard M. Stallman" <rms@gnu.org> writes:

> The image seems to show just a little of a screen.
> I am not sure what that means, but maybe I can guess.

> Do you mean that the tootip appears _partly_ off the edge of the
> screen?

Yes.

Sorry I need to give a little more explanation.  In the two images
Emacs frame is placed on the bottom edge of the screen.  When I
move the mouse pointer to the mode line, Emacs 22.0.50 tries to
place the tooltip below the mouse pointer.  But enough pixels are
not left between the point just below the mouse pointer and the
bottom edge of the screen. As a consequence the tooltip appears
partly off the edge of the screen.

Emacs 21.3 places the tooltip above the mouse pointer, thus causes
no problem in this situation.


-- 
Tetsuo Tsukamoto

Re: tooltip can be displayed outside the screen

[Richard M. Stallman]

    Sorry I need to give a little more explanation.  In the two images
    Emacs frame is placed on the bottom edge of the screen.  When I
    move the mouse pointer to the mode line, Emacs 22.0.50 tries to
    place the tooltip below the mouse pointer.  But enough pixels are
    not left between the point just below the mouse pointer and the
    bottom edge of the screen. As a consequence the tooltip appears
    partly off the edge of the screen.

Can someone please fix this and ack?

Re: tooltip can be displayed outside the screen

[Jan D.]

Richard M. Stallman wrote:

>    Sorry I need to give a little more explanation.  In the two images
>    Emacs frame is placed on the bottom edge of the screen.  When I
>    move the mouse pointer to the mode line, Emacs 22.0.50 tries to
>    place the tooltip below the mouse pointer.  But enough pixels are
>    not left between the point just below the mouse pointer and the
>    bottom edge of the screen. As a consequence the tooltip appears
>    partly off the edge of the screen.
>
>Can someone please fix this and ack?
>

Fixed.

    Jan D.

Re: tooltip can be displayed outside the screen

[Eli Zaretskii]

> Date: Fri, 02 Dec 2005 15:58:38 +0100
> From: "Jan D." <jan.h.d@swipnet.se>
> Cc: Tetsuo Tsukamoto <czkmt@remus.dti.ne.jp>, emacs-devel@gnu.org
> 
> Richard M. Stallman wrote:
> 
> >    Sorry I need to give a little more explanation.  In the two images
> >    Emacs frame is placed on the bottom edge of the screen.  When I
> >    move the mouse pointer to the mode line, Emacs 22.0.50 tries to
> >    place the tooltip below the mouse pointer.  But enough pixels are
> >    not left between the point just below the mouse pointer and the
> >    bottom edge of the screen. As a consequence the tooltip appears
> >    partly off the edge of the screen.
> >
> >Can someone please fix this and ack?
> >
> 
> Fixed.

Jan fixed this for X only; I now fixed it for w32.  I think someone
with access to the Mac needs to fix it in macfns.c.

Re: tooltip can be displayed outside the screen

[Juri Linkov]

>> >    Sorry I need to give a little more explanation.  In the two images
>> >    Emacs frame is placed on the bottom edge of the screen.  When I
>> >    move the mouse pointer to the mode line, Emacs 22.0.50 tries to
>> >    place the tooltip below the mouse pointer.  But enough pixels are
>> >    not left between the point just below the mouse pointer and the
>> >    bottom edge of the screen. As a consequence the tooltip appears
>> >    partly off the edge of the screen.
>> >
>> >Can someone please fix this and ack?
>> 
>> Fixed.
>
> Jan fixed this for X only; I now fixed it for w32.  I think someone
> with access to the Mac needs to fix it in macfns.c.

I noticed that the user option `tooltip-y-offset' doesn't do what it is
intended to do.  Instead of specifying the Y offset, it actually specifies
Y offset + height of the tooltip frame.  With a different font size
the tooltip might overlap the mouse pointer (with a bigger font) or might
be placed too far from the mouse pointer (with a smaller font).  This looks
like a bug.

OTOH, `tooltip-x-offset' properly specifies the X offset.  I suggest
to duplicate the implementation of calculating the X absolute coordinate
of the tooltip frame position, for calculating the Y absolute coordinate
with replacing `x' with `y' and `width' with `height' in the copy of the
code.  This will make the logic of these two options exactly the same.

This change will also require fixing the default value of `tooltip-y-offset'
from 40 (which currently is the sum of the real Y offset + the size of
the default font) to e.g. 18.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: tooltip can be displayed outside the screen

[Jan Djärv]

Eli Zaretskii wrote:
>>Date: Fri, 02 Dec 2005 15:58:38 +0100
>>From: "Jan D." <jan.h.d@swipnet.se>
>>Cc: Tetsuo Tsukamoto <czkmt@remus.dti.ne.jp>, emacs-devel@gnu.org
>>
>>Richard M. Stallman wrote:
>>
>>
>>>   Sorry I need to give a little more explanation.  In the two images
>>>   Emacs frame is placed on the bottom edge of the screen.  When I
>>>   move the mouse pointer to the mode line, Emacs 22.0.50 tries to
>>>   place the tooltip below the mouse pointer.  But enough pixels are
>>>   not left between the point just below the mouse pointer and the
>>>   bottom edge of the screen. As a consequence the tooltip appears
>>>   partly off the edge of the screen.
>>>
>>>Can someone please fix this and ack?
>>>
>>
>>Fixed.
> 
> 
> Jan fixed this for X only; I now fixed it for w32.  I think someone
> with access to the Mac needs to fix it in macfns.c.

Yes, sorry about that, my W32 and OSX access is nil right now.  There should 
me more code sharing, computing x and y for a tip frame should be fairly 
platform independant.  Thanks for pointing out the other ports.

	Jan D.

Re: tooltip can be displayed outside the screen

[Juri Linkov]

> Yes, sorry about that, my W32 and OSX access is nil right now.
> There should me more code sharing, computing x and y for a tip frame
> should be fairly platform independant.  Thanks for pointing out the
> other ports.

Making this computation platform independent will become a non-issue
once the code is fixed and tested.  But currently it is still not.
What do you think about fixing the meaning of `tooltip-y-offset'?
Currently `tooltip-y-offset' defines the Y offset relative to the
bottom of the tooltip frame.  But all similar options in Emacs define
offsets relative to the top (in top-left pairs).  Even `tooltip-y-offset'
allows alternative specifications in the frame parameter `top', which
differs from the current behavior of `tooltip-y-offset' which uses
the bottom of the tooltip frame.  This can be fixed by using the same
code for computing x and y.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: tooltip can be displayed outside the screen

[Jan D.]

Juri Linkov wrote:

>>Yes, sorry about that, my W32 and OSX access is nil right now.
>>There should me more code sharing, computing x and y for a tip frame
>>should be fairly platform independant.  Thanks for pointing out the
>>other ports.
>>    
>>
>
>Making this computation platform independent will become a non-issue
>once the code is fixed and tested.  But currently it is still not.
>What do you think about fixing the meaning of `tooltip-y-offset'?
>Currently `tooltip-y-offset' defines the Y offset relative to the
>bottom of the tooltip frame.  But all similar options in Emacs define
>offsets relative to the top (in top-left pairs).  Even `tooltip-y-offset'
>allows alternative specifications in the frame parameter `top', which
>differs from the current behavior of `tooltip-y-offset' which uses
>the bottom of the tooltip frame.  This can be fixed by using the same
>code for computing x and y.
>  
>

It must be a bug that the tooltip can be covered by the pointer so I've 
changed it as you suggested (for W32 and Mac also this time).  You must 
have quite a big font to see this with the default y offset.  I also 
changed the default y offset to 20 from 40.

    Jan D.

Re: tooltip can be displayed outside the screen

[Juri Linkov]

> It must be a bug that the tooltip can be covered by the pointer so
> I've changed it as you suggested (for W32 and Mac also this time).
> You must have quite a big font to see this with the default y offset.
> I also changed the default y offset to 20 from 40.

Thanks.  Now due to your changes I discovered an old bug (I can reproduce
it in Emacs 21.4) in X coordinate calculations (and now this bug also
affects Y coordinate calculations).  After setting the X offset
(or the Y offset) to a negative value, tooltips can appear partly
outside the left (or top) edge of the screen.  I'm sorry, I didn't
report this bug earlier, because I found it only now, after your
changes while trying to use negative offsets.

One idea that came to me is that negative offsets could be interpreted
as absolute distances between the X (Y) position of the mouse and the
right (bottom) border of the tooltip frame (and to leave positive offsets
relative to the left (top) border as they work now).  This way no matter
what values offsets will have, the tooltip frame will never cover the mouse
pointer.  And this will work exactly the same way as currently calculations
behave to avoid the tooltip displayed outside the screen (i.e. negating the
interpretation of offsets to opposite sides of the tooltip frame).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: tooltip can be displayed outside the screen

[Jan Djärv]

Juri Linkov wrote:

> One idea that came to me is that negative offsets could be interpreted
> as absolute distances between the X (Y) position of the mouse and the
> right (bottom) border of the tooltip frame (and to leave positive offsets
> relative to the left (top) border as they work now).  This way no matter
> what values offsets will have, the tooltip frame will never cover the mouse
> pointer.  And this will work exactly the same way as currently calculations
> behave to avoid the tooltip displayed outside the screen (i.e. negating the
> interpretation of offsets to opposite sides of the tooltip frame).
> 

That seems to complicated. I just fixed so negative offsets is handeled OK.

	Jan D.

Re: tooltip can be displayed outside the screen

[Juri Linkov]

>> One idea that came to me is that negative offsets could be interpreted
>> as absolute distances between the X (Y) position of the mouse and the
>> right (bottom) border of the tooltip frame (and to leave positive offsets
>> relative to the left (top) border as they work now).  This way no matter
>> what values offsets will have, the tooltip frame will never cover the mouse
>> pointer.  And this will work exactly the same way as currently calculations
>> behave to avoid the tooltip displayed outside the screen (i.e. negating the
>> interpretation of offsets to opposite sides of the tooltip frame).
>
> That seems to complicated. I just fixed so negative offsets is handeled OK.

OK.

BTW, I think current docstrings are not clear.  I propose to change
them as below:

Index: lisp/tooltip.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/tooltip.el,v
retrieving revision 1.70
diff -c -r1.70 tooltip.el
*** lisp/tooltip.el	12 Dec 2005 09:36:22 -0000	1.70
--- lisp/tooltip.el	15 Dec 2005 09:27:14 -0000
***************
*** 96,104 ****
  
  (defcustom tooltip-x-offset 5
    "X offset, in pixels, for the display of tooltips.
! The offset is relative to the position of the mouse.  It must
! be chosen so that the tooltip window doesn't contain the mouse
! when it pops up.
  
  If `tooltip-frame-parameters' includes the `left' parameter,
  the value of `tooltip-x-offset' is ignored."
--- 98,106 ----
  
  (defcustom tooltip-x-offset 5
    "X offset, in pixels, for the display of tooltips.
! The offset is the distance between the X position of the mouse and
! the left border of the tooltip frame.  It must be chosen so that the
! tooltip window doesn't contain the mouse when it pops up.
  
  If `tooltip-frame-parameters' includes the `left' parameter,
  the value of `tooltip-x-offset' is ignored."
***************
*** 108,116 ****
  
  (defcustom tooltip-y-offset +20
    "Y offset, in pixels, for the display of tooltips.
! The offset is relative to the position of the mouse.  It must
! be chosen so that the tooltip window doesn't contain the mouse
! when it pops up.
  
  If `tooltip-frame-parameters' includes the `top' parameter,
  the value of `tooltip-y-offset' is ignored."
--- 110,118 ----
  
  (defcustom tooltip-y-offset +20
    "Y offset, in pixels, for the display of tooltips.
! The offset is the distance between the Y position of the mouse and
! the top border of the tooltip frame.  It must be chosen so that the
! tooltip window doesn't contain the mouse when it pops up.
  
  If `tooltip-frame-parameters' includes the `top' parameter,
  the value of `tooltip-y-offset' is ignored."

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: tooltip can be displayed outside the screen

[Richard M. Stallman]

Your changes are good.  However, this text has another problem:

    ! The offset is the distance between the X position of the mouse and
    ! the left border of the tooltip frame.  It must be chosen so that the
    ! tooltip window doesn't contain the mouse when it pops up.

If you use a bad value, and the tooltip window does contain the
mouse, what happens?

Re: tooltip can be displayed outside the screen

[Juri Linkov]

> Your changes are good.  However, this text has another problem:
>
>     ! The offset is the distance between the X position of the mouse and
>     ! the left border of the tooltip frame.  It must be chosen so that the
>     ! tooltip window doesn't contain the mouse when it pops up.
>
> If you use a bad value, and the tooltip window does contain the
> mouse, what happens?

Since I am not the author of the last sentence, I don't know what it was
intended to warn against.  I tried to use a bad value on X, and the
resulted effect is the mouse pointer covering part of the tooltip window.
Also moving the mouse causes flickering of the tooltip window.  I have no
idea how to describe this behavior in the doc string.

BTW, on non-toolkit X builds using tooltips on menu items completely
garbles them.  Most likely this is caused by garbage collection, and
displaying tooltips makes GC to occur sooner than when tooltips are
disabled.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: tooltip can be displayed outside the screen

[Richard M. Stallman]

    Since I am not the author of the last sentence, I don't know what it was
    intended to warn against.  I tried to use a bad value on X, and the
    resulted effect is the mouse pointer covering part of the tooltip window.
    Also moving the mouse causes flickering of the tooltip window.  I have no
    idea how to describe this behavior in the doc string.

Could you change that to say "or it may interfere with clicking where
you wish".

    BTW, on non-toolkit X builds using tooltips on menu items completely
    garbles them.

I don't understand.  Could you please say more specifically
how they get garbled?

    Most likely this is caused by garbage collection, and
    displaying tooltips makes GC to occur sooner than when tooltips are
    disabled.

I don't follow the connection.  What does GC have to do with garbling
tooltips?

Are you using a mode in which the tooltip appears in the echo area?

GC garbles menu items (was: tooltip can be displayed outside the screen)

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 274 bytes --]

>     BTW, on non-toolkit X builds using tooltips on menu items completely
>     garbles them.
>
> I don't understand.  Could you please say more specifically
> how they get garbled?

Menu items get garbled in such a way that after moving the mouse pointer
over menu items


[-- Attachment #2: menu11.png --]
[-- Type: image/png, Size: 2050 bytes --]

[-- Attachment #3: Type: text/plain, Size: 22 bytes --]


the menu changes to


[-- Attachment #4: menu12.png --]
[-- Type: image/png, Size: 2317 bytes --]

[-- Attachment #5: Type: text/plain, Size: 861 bytes --]


>     Most likely this is caused by garbage collection, and
>     displaying tooltips makes GC to occur sooner than when tooltips are
>     disabled.
>
> I don't follow the connection.  What does GC have to do with garbling
> tooltips?

Displaying the tooltip frame while a menu is displayed requires some Lisp
consing, so GC starts sooner and it garbles menu items while menus are
still displayed.

> Are you using a mode in which the tooltip appears in the echo area?

This bug can be reproduced even when the tooltip appears in the echo area.
I guess displaying the tooltip in the echo area requires less consing,
so GC activates later than when the tooltip appears in the separate window.

So the bug is not in tooltips, but in GC which garbles menu items.

I can reproduce this bug only on non-toolkit builds.

-- 
Juri Linkov
http://www.jurta.org/emacs/

[-- Attachment #6: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: GC garbles menu items (was: tooltip can be displayed outside the screen)

[Richard M. Stallman]

    I can reproduce this bug only on non-toolkit builds.

Aha, now I see.  The non-toolkit definition of xmenu_show copies the
addresses of string text directly into the non-toolkit menu data.
When GC happens, it relocates the strings and garbles the text.

Could you rewrite that code to copy the strings when making the menus,
and free the copies at the end?


I think that code was written before we made Emacs GC during idle time
and before there were timers.  Back then, it was probably impossible
to GC while the menu was up.

Re: GC garbles menu items

[Juri Linkov]

>     I can reproduce this bug only on non-toolkit builds.
>
> Aha, now I see.  The non-toolkit definition of xmenu_show copies the
> addresses of string text directly into the non-toolkit menu data.
> When GC happens, it relocates the strings and garbles the text.

Is it possible to prevent relocation of the strings in GC for the time
while the menu is up?

> Could you rewrite that code to copy the strings when making the menus,
> and free the copies at the end?

I think it's safer not to change memory allocation code in non-toolkit
XMenu now just before the release.  I believe it is possible to solve
this problem by preventing string relocation the same way as it is done
for menu items where keyboard equivalents are displayed in the same menu
item.  Such menu items are constructed by the following code in xmenu_show
(and GC doesn't corrupt these menu items):

#ifdef C_ALLOCA
	      Lisp_Object spacer;
	      spacer = Fmake_string (make_number (gap), make_number (' '));
	      item_name = concat2 (item_name, spacer);
	      item_name = concat2 (item_name, descrip);
	      item_data = SDATA (item_name);
#else
	      /* if alloca is fast, use that to make the space,
		 to reduce gc needs.  */
	      item_data
		= (unsigned char *) alloca (maxwidth
					    + SBYTES (descrip) + 1);
	      bcopy (SDATA (item_name), item_data,
		     SBYTES (item_name));
	      for (j = SCHARS (item_name); j < maxwidth; j++)
		item_data[j] = ' ';
	      bcopy (SDATA (descrip), item_data + j,
		     SBYTES (descrip));
	      item_data[j + SBYTES (descrip)] = 0;
#endif

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: GC garbles menu items

[Richard M. Stallman]

    Is it possible to prevent relocation of the strings in GC for the time
    while the menu is up?

There is no feature to stop GC from relocating strings.  Adding one
would be a much more radical and risky change.  I don't want to do
that now, and perhaps not later.

What would be easier to do is turn off GC while the menu is up.  There
is already a way to do that: call inhibit_garbage_collection.  Does this
patch fix it?

*** xmenu.c	21 Dec 2005 19:38:13 -0500	1.297
--- xmenu.c	22 Dec 2005 00:36:37 -0500	
***************
*** 3343,3348 ****
--- 3343,3350 ----
        return Qnil;
      }
  
+   inhibit_garbage_collection ();
+ 
  #ifdef HAVE_X_WINDOWS
    /* Adjust coordinates to relative to the outer (window manager) window.  */
    x += FRAME_OUTER_TO_INNER_DIFF_X (f);

You also wrote:

      I believe it is possible to solve
    this problem by preventing string relocation the same way as it is done
    for menu items where keyboard equivalents are displayed in the same menu
    item.  Such menu items are constructed by the following code in xmenu_show
    (and GC doesn't corrupt these menu items):

What it is doing is copying the strings to the stack.  Indeed, that
technique should work.

Note that the code in the C_ALLOCA case probably has the same kind of
bug that we are discussing, because it creates a Lisp string that
could be moved:

		  Lisp_Object spacer;
		  spacer = Fmake_string (make_number (gap), make_number (' '));
		  item_name = concat2 (item_name, spacer);
		  item_name = concat2 (item_name, descrip);
		  item_data = SDATA (item_name);

It probably doesn't matter, because probably nobody uses the C_ALLOCA
case any more.  I would expect that all those configurations have been
obsolete for years.  Anyway, my patch should fix that too.

Re: GC garbles menu items

[Juri Linkov]

> What would be easier to do is turn off GC while the menu is up.  There
> is already a way to do that: call inhibit_garbage_collection.  Does this
> patch fix it?

Yes.

-- 
Juri Linkov
http://www.jurta.org/emacs/