Re: 23.1.92; `x-show-tip' and `tooltip-frame-parameters' do not respect `left' and `top'

Re: 23.1.92; `x-show-tip' and `tooltip-frame-parameters' do not respect `left' and `top'

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> wrote:

> M-: (x-show-tip "aaaaaaaa" (selected-frame) '((left . 30) (top . 40)) 10 0 0)
>
> Instead of displaying the tooltip frame at the absolute
> location specified by `left' and `top', it always displays it at the mouse
> position plus the DX and DY (0 and 0 here).

This is reported to be a regression against Emacs 22.  Unfortunately,
it's Windows-only, and I can't reproduce it.  Could someone with access
to a Windows box give it a shot?

Re: 23.1.92; `x-show-tip' and `tooltip-frame-parameters' do not respect `left' and `top'

[Christoph]

On 3/13/2010 1:15 PM, Chong Yidong wrote:
> "Drew Adams"<drew.adams@oracle.com>  wrote:
>
>    
>> M-: (x-show-tip "aaaaaaaa" (selected-frame) '((left . 30) (top . 40)) 10 0 0)
>>
>> Instead of displaying the tooltip frame at the absolute
>> location specified by `left' and `top', it always displays it at the mouse
>> position plus the DX and DY (0 and 0 here).
>>      
> This is reported to be a regression against Emacs 22.  Unfortunately,
> it's Windows-only, and I can't reproduce it.  Could someone with access
> to a Windows box give it a shot
Emacs 23.1.93.1 (Pretest) on Windows 7: the tooltip follows the mouse as 
described. Also, the tooltip is only visible when the mouse is NOT 
within the Emacs window but somewhere else on the desktop. Then the 
tooltip appears with the mouse cursor pointing to the upper left corner. 
It does not appear at all when the mouse cursor is within the bounds of 
the Emacs window. Therefore, in full screen mode the tooltip never appears.

Christoph

RE: 23.1.92; `x-show-tip' and `tooltip-frame-parameters' do not respect `left' and `top'

[Drew Adams]

> >> M-: (x-show-tip "aaaaaaaa" (selected-frame) '((left . 30) 
> >> (top . 40)) 10 0 0)
> >>
> >> Instead of displaying the tooltip frame at the absolute
> >> location specified by `left' and `top', it always displays 
> >> it at the mouse position plus the DX and DY (0 and 0 here).
> >>      
> > This is reported to be a regression against Emacs 22.  
> > Unfortunately, it's Windows-only, and I can't reproduce it.
> > Could someone with access to a Windows box give it a shot
>
> Emacs 23.1.93.1 (Pretest) on Windows 7: the tooltip follows 
> the mouse as described. Also, the tooltip is only visible
> when the mouse is NOT within the Emacs window but somewhere
> else on the desktop. Then the tooltip appears with the mouse
> cursor pointing to the upper left corner. It does not appear
> at all when the mouse cursor is within the bounds of 
> the Emacs window. Therefore, in full screen mode the tooltip 
> never appears.

Hm. That's not what I see, in GNU Emacs 23.1.92.1  (i386-mingw-nt5.1.2600) of
2010-02-20 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.',
version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags
-Ic:/g/include -fno-crossjumping'.

In my case, the tooltip does appear when the mouse pointer is within the window.

But at least you confirm that the frame parameters `left' and `top' are being
ignored and the tooltip appears at the mouse position (when it appears, in your
case).

Re: 23.1.92; `x-show-tip' and `tooltip-frame-parameters' do not respect `left' and `top'

[Eli Zaretskii]

> Date: Sat, 13 Mar 2010 15:03:28 -0700
> From: Christoph <cschol2112@googlemail.com>
> 
> Also, the tooltip is only visible when the mouse is NOT 
> within the Emacs window but somewhere else on the desktop.

That's not accurate: the tooltip actually appears, but is immediately
removed.  My guess is that this happens because the redisplay that
immediately follows the tooltip's popup removes the tooltip.

If the mouse pointer is on some part of the Emacs frame that isn't
redrawn by the redisplay, or outside the Emacs frame, the tooltip
stays.

Re: bug#5703: 23.1.92; `x-show-tip' and `tooltip-frame-parameters' do not respect `left' and `top'

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sat, 13 Mar 2010 15:15:12 -0500
> Cc: 5703@debbugs.gnu.org
> 
> "Drew Adams" <drew.adams@oracle.com> wrote:
> 
> > M-: (x-show-tip "aaaaaaaa" (selected-frame) '((left . 30) (top . 40)) 10 0 0)
> >
> > Instead of displaying the tooltip frame at the absolute
> > location specified by `left' and `top', it always displays it at the mouse
> > position plus the DX and DY (0 and 0 here).
> 
> This is reported to be a regression against Emacs 22.  Unfortunately,
> it's Windows-only, and I can't reproduce it.  Could someone with access
> to a Windows box give it a shot?

I think the small patch below fixes this.  But since this is about
pretest, I would like second opinion on that from anyone who is
familiar with this stuff (not only on MS-Windows).  In particular, I'd
like to hear from Jason.

Please also try the patched version in as many different use-cases as
you can, to make sure it doesn't break anything.

Here's what I found to be the reason of the bug:

compute_tip_xy relies on the tip frame's parameters (passed to it
through the `parms' argument) for figuring out where to display the
tooltip.  But by the time compute_tip_xy is called, the `top' and
`left' parameters were already removed from `parms'.  That's because
x_create_tip_frame, called a few lines before that, calls
x_figure_window_size, which sets up f->top_pos and f->left_pos from
`top' and `left', and as a side effect removes them from the frame's
parameters alist.

I see almost identical code in xfns.c versions of these functions, so
I'd be interested to hear how come the X version does not suffer from
the same problem.  That's because the patch below, although it does
the job, feels a bit kludgey, and I wonder if there a cleaner way.

=== modified file 'src/w32fns.c'
--- src/w32fns.c	2010-01-13 08:35:10 +0000
+++ src/w32fns.c	2010-03-30 12:57:13 +0000
@@ -5927,6 +5927,10 @@ Text larger than the specified size is c
   /* Move the tooltip window where the mouse pointer is.  Resize and
      show it.  */
   compute_tip_xy (f, parms, dx, dy, width, height, &root_x, &root_y);
+  if (f->top_pos)
+    root_y = f->top_pos;
+  if (f->left_pos)
+    root_x = f->left_pos;
 
   {
     /* Adjust Window size to take border into account.  */

Re: bug#5703: 23.1.92; `x-show-tip' and `tooltip-frame-parameters' do not respect `left' and `top'

[Jason Rumney]

Eli Zaretskii <eliz@gnu.org> writes:

> I think the small patch below fixes this.  But since this is about
> pretest, I would like second opinion on that from anyone who is
> familiar with this stuff (not only on MS-Windows).  In particular, I'd
> like to hear from Jason.

If I understand your patch correctly, what you are effectively doing is
to compute the x and y location of the tooltip, then patch it up
afterwards if explicit arguments were given.  This seems ok for a
temporary workaround until the reason Windows behaviour differs from
other plaforms can be found.


> === modified file 'src/w32fns.c'
> --- src/w32fns.c	2010-01-13 08:35:10 +0000
> +++ src/w32fns.c	2010-03-30 12:57:13 +0000
> @@ -5927,6 +5927,10 @@ Text larger than the specified size is c
>    /* Move the tooltip window where the mouse pointer is.  Resize and
>       show it.  */
>    compute_tip_xy (f, parms, dx, dy, width, height, &root_x, &root_y);
> +  if (f->top_pos)
> +    root_y = f->top_pos;
> +  if (f->left_pos)
> +    root_x = f->left_pos;
>  
>    {
>      /* Adjust Window size to take border into account.  */

Re: bug#5703: 23.1.92; `x-show-tip' and `tooltip-frame-parameters' do not respect `left' and `top'

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Cc: Chong Yidong <cyd@stupidchicken.com>,  emacs-devel@gnu.org,  5703@debbugs.gnu.org
> Date: Tue, 30 Mar 2010 22:41:11 +0800
> 
> If I understand your patch correctly, what you are effectively doing is
> to compute the x and y location of the tooltip, then patch it up
> afterwards if explicit arguments were given.

That's right.  That's why I said it felt kludgey.

> This seems ok for a temporary workaround until the reason Windows
> behaviour differs from other plaforms can be found.

Thanks for the feedback.

Re: bug#5703: 23.1.92; `x-show-tip' and `tooltip-frame-parameters' do not respect `left' and `top'

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 30 Mar 2010 16:15:37 +0300, Eli Zaretskii <eliz@gnu.org> said:

> compute_tip_xy relies on the tip frame's parameters (passed to it
> through the `parms' argument) for figuring out where to display the
> tooltip.  But by the time compute_tip_xy is called, the `top' and
> `left' parameters were already removed from `parms'.  That's because
> x_create_tip_frame, called a few lines before that, calls
> x_figure_window_size, which sets up f->top_pos and f->left_pos from
> `top' and `left', and as a side effect removes them from the frame's
> parameters alist.

> I see almost identical code in xfns.c versions of these functions,
> so I'd be interested to hear how come the X version does not suffer
> from the same problem.  That's because the patch below, although it
> does the job, feels a bit kludgey, and I wonder if there a cleaner
> way.

Because x_create_tip_frame in xfns.c makes a copy of `parms'?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: bug#5703: 23.1.92; `x-show-tip' and `tooltip-frame-parameters' do not respect `left' and `top'

[Eli Zaretskii]

> Date: Wed, 31 Mar 2010 08:33:25 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: Chong Yidong <cyd@stupidchicken.com>, emacs-devel@gnu.org,
> 	5703@debbugs.gnu.org, jasonr@gnu.org
> 
> > I see almost identical code in xfns.c versions of these functions,
> > so I'd be interested to hear how come the X version does not suffer
> > from the same problem.  That's because the patch below, although it
> > does the job, feels a bit kludgey, and I wonder if there a cleaner
> > way.
> 
> Because x_create_tip_frame in xfns.c makes a copy of `parms'?

Right, I missed that.  Thanks.

So I committed to the emacs-23 branch the following patch which fixes
the bug:

  === modified file 'src/ChangeLog'
  --- src/ChangeLog	2010-03-31 04:00:23 +0000
  +++ src/ChangeLog	2010-03-31 09:08:40 +0000
  @@ -1,3 +1,8 @@
  +2010-03-31  Eli Zaretskii  <eliz@gnu.org>
  +
  +	* w32fns.c (x_create_tip_frame): Copy `parms' before we modify it
  +	in this function.  (Bug#5703)
  +
   2010-03-31  Chong Yidong  <cyd@stupidchicken.com>

	  * nsterm.h: Fix last change.

  === modified file 'src/w32fns.c'
  --- src/w32fns.c	2010-01-13 08:35:10 +0000
  +++ src/w32fns.c	2010-03-31 09:08:40 +0000
  @@ -5427,6 +5427,10 @@ x_create_tip_frame (dpyinfo, parms, text

     kb = dpyinfo->terminal->kboard;

  +  /* The calls to x_get_arg remove elements from PARMS, so copy it to
  +     avoid destructive changes behind our caller's back.  */
  +  parms = Fcopy_alist (parms);
  +
     /* Get the name of the frame to use for resource lookup.  */
     name = x_get_arg (dpyinfo, parms, Qname, "name", "Name", RES_TYPE_STRING);
     if (!STRINGP (name)