GNU bug report logs - #76321
31.0.50; Moving nested child frames out of their child parents

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 76321 in the body.
You can then email your comments to 76321 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Moving nested child frames out of their child parents
Date: Sun, 16 Feb 2025 06:16:02 +0100

[Message part 1 (text/plain, inline)]

This bug is for something Martin Rudalics found:

There's a problem with moving nested child frames out of their child
parents.  Load the attached tty-child-frames.el do first M-l and then
C-M-l.  You should see a grey child frame embedded in an orange child
frame.  Now do

(set-frame-parameter tty-3 'left (- 30))

[martin.el (application/emacs-lisp, attachment)]

[Message part 3 (text/plain, inline)]

In GNU Emacs 31.0.50 (build 2, aarch64-apple-darwin24.3.0, NS
 appkit-2575.40 Version 15.3.1 (Build 24D70)) of 2025-02-15 built on
 pro2
Repository revision: 4cf53c436159ea54dbfe1a1e24515e2e6fbf9a6f
Repository branch: master
System Description:  macOS 15.3.1

Message #8 received at 76321 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: 76321 <at> debbugs.gnu.org
Subject: Re: bug#76321: 31.0.50; Moving nested child frames out of their
 child parents
Date: Sun, 16 Feb 2025 07:00:40 +0100

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> This bug is for something Martin Rudalics found:
>
> There's a problem with moving nested child frames out of their child
> parents.  Load the attached tty-child-frames.el do first M-l and then
> C-M-l.  You should see a grey child frame embedded in an orange child
> frame.  Now do
>
> (set-frame-parameter tty-3 'left (- 30))

An observation: When I modify the frame creation like this

(defun tty-3 ()
  (interactive)
  (setq tty-3
	(make-frame
	 `((parent-frame . ,tty-2)
	   (left . (- 30)) (top . 5)
                   ^^^^^^
	   (width . 10) (height . 5)

and then do M-l and C-M-l, tty-3 is displayed at a different location
than after the modify-frame-parameter. This is an indication that there
is an inconsistency somewhere.

Elisp info says about frame parameter 'left':

     ‘(- POS)’
          This specifies the position of the right frame edge relative
          to the right edge of the display or parent frame.  The integer
          POS may be positive or negative; a negative value specifies a
          position outside the screen or parent frame or on a monitor
          other than the primary one (for multi-monitor displays).

Parent frame tty-2 of tty-3 has

	 `((parent-frame . ,root-frame)
	   (left . 40) (top . 5)
	   (width . 30) (height . 20)

tty-2's right edges is at 40 + 30 = 70, in root coordinates.

So, the right edge of tty-3 should land at 70, which makes its left edge
should be 70 - 10 = 60.

That is absolutely not what I'm seeing, neither with the initial (- 30)
for left nor after modify-frame-parameters. So I guess my reading of
Elisp info is wrong?

Martin, could you please help me with this? What is the intended effect
of the (- 30), do you know?

Message #11 received at 76321 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: 76321 <at> debbugs.gnu.org
Cc: Martin Rudalics <rudalics <at> gmx.at>
Subject: Re: bug#76321: 31.0.50; Moving nested child frames out of their
 child parents
Date: Sun, 16 Feb 2025 07:02:48 +0100

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> This bug is for something Martin Rudalics found:
>>
>> There's a problem with moving nested child frames out of their child
>> parents.  Load the attached tty-child-frames.el do first M-l and then
>> C-M-l.  You should see a grey child frame embedded in an orange child
>> frame.  Now do
>>
>> (set-frame-parameter tty-3 'left (- 30))
>
> An observation: When I modify the frame creation like this
>
> (defun tty-3 ()
>   (interactive)
>   (setq tty-3
> 	(make-frame
> 	 `((parent-frame . ,tty-2)
> 	   (left . (- 30)) (top . 5)
>                    ^^^^^^
> 	   (width . 10) (height . 5)
>
> and then do M-l and C-M-l, tty-3 is displayed at a different location
> than after the modify-frame-parameter. This is an indication that there
> is an inconsistency somewhere.
>
> Elisp info says about frame parameter 'left':
>
>      ‘(- POS)’
>           This specifies the position of the right frame edge relative
>           to the right edge of the display or parent frame.  The integer
>           POS may be positive or negative; a negative value specifies a
>           position outside the screen or parent frame or on a monitor
>           other than the primary one (for multi-monitor displays).
>
> Parent frame tty-2 of tty-3 has
>
> 	 `((parent-frame . ,root-frame)
> 	   (left . 40) (top . 5)
> 	   (width . 30) (height . 20)
>
> tty-2's right edges is at 40 + 30 = 70, in root coordinates.
>
> So, the right edge of tty-3 should land at 70, which makes its left edge
> should be 70 - 10 = 60.
>
> That is absolutely not what I'm seeing, neither with the initial (- 30)
> for left nor after modify-frame-parameters. So I guess my reading of
> Elisp info is wrong?
>
> Martin, could you please help me with this? What is the intended effect
> of the (- 30), do you know?

Forgot to CC Martin, of course. 

Message #14 received at 76321 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 76321 <at> debbugs.gnu.org
Subject: Re: bug#76321: 31.0.50; Moving nested child frames out of their child
 parents
Date: Sun, 16 Feb 2025 10:00:25 +0100

[Message part 1 (text/plain, inline)]

>> An observation: When I modify the frame creation like this
>>
>> (defun tty-3 ()
>>    (interactive)
>>    (setq tty-3
>> 	(make-frame
>> 	 `((parent-frame . ,tty-2)
>> 	   (left . (- 30)) (top . 5)
>>                     ^^^^^^
>> 	   (width . 10) (height . 5)
>>
>> and then do M-l and C-M-l, tty-3 is displayed at a different location
>> than after the modify-frame-parameter. This is an indication that there
>> is an inconsistency somewhere.
>>
>> Elisp info says about frame parameter 'left':
>>
>>       ‘(- POS)’
>>            This specifies the position of the right frame edge relative
>>            to the right edge of the display or parent frame.  The integer
>>            POS may be positive or negative; a negative value specifies a
>>            position outside the screen or parent frame or on a monitor
>>            other than the primary one (for multi-monitor displays).
>>
>> Parent frame tty-2 of tty-3 has
>>
>> 	 `((parent-frame . ,root-frame)
>> 	   (left . 40) (top . 5)
>> 	   (width . 30) (height . 20)
>>
>> tty-2's right edges is at 40 + 30 = 70, in root coordinates.

Hopefully.

>> So, the right edge of tty-3 should land at 70, which makes its left edge
>> should be 70 - 10 = 60.

The right edge of tty-3 should land at 70 - 30 = 40 in root coordinates
and its left edge at 40 - 10 = 30 in root coordinates which means, given
that tty-2's left is at 40 in root coordinates, tty-3 should be
invisible.

>> That is absolutely not what I'm seeing, neither with the initial (- 30)
>> for left nor after modify-frame-parameters. So I guess my reading of
>> Elisp info is wrong?
>>
>> Martin, could you please help me with this? What is the intended effect
>> of the (- 30), do you know?

The old code in tty_child_pos_param is wrong.  I'm using


tty_child_pos_param (struct frame *f, Lisp_Object key,
		     Lisp_Object params, int pos)
{
  struct frame *p = XFRAME (f->parent_frame);
  Lisp_Object val = Fassq (key, params);

  if (CONSP (val))
    {
      val = XCDR (val);

      if (TYPE_RANGED_FIXNUMP (int, val))
	{
	  pos = XFIXNUM (val);

	  if (pos < 0) ; <------------ see here !!!!!
	    /* Handle negative value. */
	    pos = (EQ (key, Qtop)
		   ? p->pixel_height - f->pixel_height + pos
		   : p->pixel_width - f->pixel_width + pos);
	}
      else if (CONSP (val) && EQ (XCAR (val), Qplus)
	       && CONSP (XCDR (val))
	       && TYPE_RANGED_FIXNUMP (int, XCAR (XCDR (val))))
	pos = XFIXNUM (XCAR (XCDR (val)));
      else if (CONSP (val) && EQ (XCAR (val), Qminus)
	       && CONSP (XCDR (val))
	       && RANGED_FIXNUMP (-INT_MAX, XCAR (XCDR (val)), INT_MAX))
	pos = (EQ (key, Qtop)
	       ? p->pixel_height - f->pixel_height - XFIXNUM (XCAR (XCDR (val)))
	       : p->pixel_width - f->pixel_width - XFIXNUM (XCAR (XCDR (val))));
    }

  return pos;
}


and am still not entirely convinced that it's right.  I attach my
current changes.

martin

[child-frame-menubar-drag-resize.diff (text/x-patch, attachment)]

Message #17 received at 76321 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 76321 <at> debbugs.gnu.org
Subject: Re: bug#76321: 31.0.50; Moving nested child frames out of their
 child parents
Date: Sun, 16 Feb 2025 10:14:43 +0100

martin rudalics <rudalics <at> gmx.at> writes:

>>> An observation: When I modify the frame creation like this
>>>
>>> (defun tty-3 ()
>>>    (interactive)
>>>    (setq tty-3
>>> 	(make-frame
>>> 	 `((parent-frame . ,tty-2)
>>> 	   (left . (- 30)) (top . 5)
>>>                     ^^^^^^
>>> 	   (width . 10) (height . 5)
>>>
>>> and then do M-l and C-M-l, tty-3 is displayed at a different location
>>> than after the modify-frame-parameter. This is an indication that there
>>> is an inconsistency somewhere.
>>>
>>> Elisp info says about frame parameter 'left':
>>>
>>>       ‘(- POS)’
>>>            This specifies the position of the right frame edge relative
>>>            to the right edge of the display or parent frame.  The integer
>>>            POS may be positive or negative; a negative value specifies a
>>>            position outside the screen or parent frame or on a monitor
>>>            other than the primary one (for multi-monitor displays).
>>>
>>> Parent frame tty-2 of tty-3 has
>>>
>>> 	 `((parent-frame . ,root-frame)
>>> 	   (left . 40) (top . 5)
>>> 	   (width . 30) (height . 20)
>>>
>>> tty-2's right edges is at 40 + 30 = 70, in root coordinates.
>
> Hopefully.
>
>>> So, the right edge of tty-3 should land at 70, which makes its left edge
>>> should be 70 - 10 = 60.
>
> The right edge of tty-3 should land at 70 - 30 = 40 in root coordinates
> and its left edge at 40 - 10 = 30 in root coordinates which means, given
> that tty-2's left is at 40 in root coordinates, tty-3 should be
> invisible.

I see. Relative to the right edge of tty-2 = 70 - 30. I guess I got
confused by to two 30's. One for the with of tty-2 and the other from (-
30). And not enough coffein :-).

>>> That is absolutely not what I'm seeing, neither with the initial (- 30)
>>> for left nor after modify-frame-parameters. So I guess my reading of
>>> Elisp info is wrong?
>>>
>>> Martin, could you please help me with this? What is the intended effect
>>> of the (- 30), do you know?
>
> The old code in tty_child_pos_param is wrong.  I'm using
>
>
> tty_child_pos_param (struct frame *f, Lisp_Object key,
> 		     Lisp_Object params, int pos)
> {
>   struct frame *p = XFRAME (f->parent_frame);
>   Lisp_Object val = Fassq (key, params);
>
>   if (CONSP (val))
>     {
>       val = XCDR (val);
>
>       if (TYPE_RANGED_FIXNUMP (int, val))
> 	{
> 	  pos = XFIXNUM (val);
>
> 	  if (pos < 0) ; <------------ see here !!!!!
> 	    /* Handle negative value. */
> 	    pos = (EQ (key, Qtop)
> 		   ? p->pixel_height - f->pixel_height + pos
> 		   : p->pixel_width - f->pixel_width + pos);
> 	}
>       else if (CONSP (val) && EQ (XCAR (val), Qplus)
> 	       && CONSP (XCDR (val))
> 	       && TYPE_RANGED_FIXNUMP (int, XCAR (XCDR (val))))
> 	pos = XFIXNUM (XCAR (XCDR (val)));
>       else if (CONSP (val) && EQ (XCAR (val), Qminus)
> 	       && CONSP (XCDR (val))
> 	       && RANGED_FIXNUMP (-INT_MAX, XCAR (XCDR (val)), INT_MAX))
> 	pos = (EQ (key, Qtop)
> 	       ? p->pixel_height - f->pixel_height - XFIXNUM (XCAR (XCDR (val)))
> 	       : p->pixel_width - f->pixel_width - XFIXNUM (XCAR (XCDR (val))));
>     }
>
>   return pos;
> }
>
>
> and am still not entirely convinced that it's right.  I attach my
> current changes.
>
> martin

Thanks. This frame parameter stuff is sooo over-engineered :-/.

Does it work with your changes, or is it still crashing?

Message #20 received at 76321 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 76321 <at> debbugs.gnu.org
Subject: Re: bug#76321: 31.0.50; Moving nested child frames out of their child
 parents
Date: Sun, 16 Feb 2025 11:09:00 +0100

> Thanks. This frame parameter stuff is sooo over-engineered :-/.

Don't ask me how much time I spent on it.  The most important thing
would be to make values more characteristic - instead of 40 use 39 ...

> Does it work with your changes, or is it still crashing?

I found the crash when I tried to drag a child frame's child with the
mouse.  So yes, it's crashing with my changes.

martin

Message #23 received at 76321 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 76321 <at> debbugs.gnu.org
Subject: Re: bug#76321: 31.0.50; Moving nested child frames out of their
 child parents
Date: Mon, 17 Feb 2025 10:52:22 +0100

[Message part 1 (text/plain, inline)]

martin rudalics <rudalics <at> gmx.at> writes:

>> Thanks. This frame parameter stuff is sooo over-engineered :-/.
>
> Don't ask me how much time I spent on it.  The most important thing
> would be to make values more characteristic - instead of 40 use 39 ...
>
>> Does it work with your changes, or is it still crashing?
>
> I found the crash when I tried to drag a child frame's child with the
> mouse.  So yes, it's crashing with my changes.
>
> martin

I've found the reason, please see the attached patch. If it works for
you, I'll put in master.

With your latest diff, and nothing additional on top of it, and with

(defun tty-3 ()
  (interactive)
  (setq tty-3
	(make-frame
	 `((parent-frame . ,tty-2)
	   (left . (- 10)) (top . 5)
                   ^^^^^^^

the placement of tty-3 seems wrong. Just saying, I think you mentioned
that you fixed that already.

[0001-Fix-child-coordinate-calculation-bug-76321.patch (text/x-patch, attachment)]

Message #26 received at 76321 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 76321 <at> debbugs.gnu.org
Subject: Re: bug#76321: 31.0.50; Moving nested child frames out of their child
 parents
Date: Mon, 17 Feb 2025 11:14:11 +0100

> I've found the reason, please see the attached patch. If it works for
> you, I'll put in master.

Thanks.  No more crashes.  It now behaves IIRC as with the NS builds
where child frames can be freely moved around the root frame or display.
On a GTK GUI frame they become invisible whenever they leave their
parents' rectangles.  I won't object your choice but maybe someone else
will.

> With your latest diff, and nothing additional on top of it, and with
>
> (defun tty-3 ()
>    (interactive)
>    (setq tty-3
> 	(make-frame
> 	 `((parent-frame . ,tty-2)
> 	   (left . (- 10)) (top . 5)
>                     ^^^^^^^
>
> the placement of tty-3 seems wrong. Just saying, I think you mentioned
> that you fixed that already.

I didn't fix that yet.  What's needed here is to accumulate the sizes
and/or positions of all ancestor frames.

martin

Message #29 received at 76321 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 76321 <at> debbugs.gnu.org
Subject: Re: bug#76321: 31.0.50; Moving nested child frames out of their
 child parents
Date: Mon, 17 Feb 2025 11:30:07 +0100

martin rudalics <rudalics <at> gmx.at> writes:

>> I've found the reason, please see the attached patch. If it works for
>> you, I'll put in master.
>
> Thanks.  No more crashes.  

👍

> It now behaves IIRC as with the NS builds where child frames can be
> freely moved around the root frame or display. On a GTK GUI frame they
> become invisible whenever they leave their parents' rectangles. I
> won't object your choice but maybe someone else will.

Yes, it's like in macOS with GUI frames. It's the only platform I've
used child frames on :-).

>
>> With your latest diff, and nothing additional on top of it, and with
>>
>> (defun tty-3 ()
>>    (interactive)
>>    (setq tty-3
>> 	(make-frame
>> 	 `((parent-frame . ,tty-2)
>> 	   (left . (- 10)) (top . 5)
>>                     ^^^^^^^
>>
>> the placement of tty-3 seems wrong. Just saying, I think you mentioned
>> that you fixed that already.
>
> I didn't fix that yet.  What's needed here is to accumulate the sizes
> and/or positions of all ancestor frames.

Thanks for confirming that it works! Pushed, and closing.

Previous Next

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