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

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

[Drew Adams]

emacs -Q

M-: (x-show-tip "aaaaaaaa" (selected-frame)
                '((left . 30) (top . 40)) 10 0 0)

Or something similar. 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).

Also, the tooltip does not remain displayed for the 10 seconds specified, but
perhaps that is due to the way this is evaluated (M-:).

As another example (easier to see), evaluate this:

(let ((tooltip-frame-parameters '((nil . "tooltip")
                                  (left . 100)
                                  (top . 200))))
  (tooltip-show "aaaaaaaaa" nil))

In this case, the tooltip is always shown with an offset of 5 (the default DX
and DY) from the mouse pointer. 

The `left' and `right' parameters are ignored. Even the doc string of
`tooltip-frame-parameters' says that `left' and `top' should be respected.
Instead, the mouse pointer position is always used.

Another illustration:

M-: (my-show "aaaaaa" nil 100 200)

where `my-show' is the same as `tooltip-show' except that it accepts optional
LEFT and TOP params, to override `tooltip-frame-parameters':

(defun my-show (text &optional use-echo-area left top)
  "..."
  (if use-echo-area
      (tooltip-show-help-non-mode text)
    (condition-case error
	(let ((params (copy-sequence tooltip-frame-parameters))
	      (fg (face-attribute 'tooltip :foreground))
	      (bg (face-attribute 'tooltip :background)))
	  (when (stringp fg)
	    (setq params (tooltip-set-param params 'foreground-color fg))
	    (setq params (tooltip-set-param params 'border-color fg)))
	  (when (stringp bg)
	    (setq params (tooltip-set-param params 'background-color bg)))
          (when left (setq params  (tooltip-set-param params 'left left)))
          (when top  (setq params  (tooltip-set-param params 'top top)))
	  (x-show-tip (propertize text 'face 'tooltip)
		      (selected-frame)
		      params
		      tooltip-hide-delay
		      tooltip-x-offset
		      tooltip-y-offset))
      (error
       (message "Error while displaying tooltip: %s" error)
       (sit-for 1)
       (message "%s" text)))))

`tooltip-show' should in fact be modified in this way (adding optional LEFT and
TOP), IMO, so that you can easily show the tooltip anywhere without first adding
the location to `tooltip-frame-parameters' (e.g. as in the `let' example). But
the bug needs to be fixed first.


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'

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

[Drew Adams]

This is a regression - it works fine in Emacs 22. It is broken starting with
Emacs 23.1.

After fixing, please add optional LEFT and TOP parameters.

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

[Drew Adams]

FYI - One person on Emacs Wiki reported that he couldn't reproduce this, so it
might be Windows-specific. HTH.

bug#5703: 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?

bug#5703: 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).

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

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

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.

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

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)