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?

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

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

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

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'

[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: 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.

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'

[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.

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.

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'

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

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)