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

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 76321 <at> debbugs.gnu.org
Subject: 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?

Previous Next

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