GNU bug report logs -
#65217
29.1; set-frame-size gets confused and drops calls
Previous Next
Full log
Message #77 received at 65217 <at> debbugs.gnu.org (full text, mbox):
>> I'm not sure what you mean by "works correctly". That exact recipe
>> (with emacs -Q -l file.el) produces either a 10x10 frame or a 20x20
>> frame, randomly but apparently equally distributed. Adding a (sit-for
>> 0) after the first call to set-frame-size does not help.
>
> Can you check whether input is pending before the 'sit-for' call?
>
input-pending-p invariably returns t in that recipe.
>> But adding a (redisplay t) after the first call to set-frame-size
>> helps: the result is then always a 20x20 frame.
>
> Here it works with FORCE nil too.
>
Indeed, here it works also with simply (redisplay), with the recipe for
normal frames. I guess (redisplay t) is a bit safer though.
>
> (sleep-for 0.001) works here too. I see problems with (sleep-for
> 0.00000000000000000000000000000000000000000000000001).
>
(sleep-for 0.001) between the two calls to set-frame-size, in the recipe
for normal frames, doesn't work here, most often the child frame is 10x10,
sometimes it is 20x20. However, (sleep-for 0.001) before the two calls to
set-frame-size does work, the child frame is always 20x20.
>> One problem remains, however: the message is still either "10 10" or
>> "20 20".
>
> Always 10x10 wouldn't be that bad. The "either" means that some race
> condition persists. Here I get always "20x20" with the redisplay call.
>
I just tried again to run the recipe for normal frames 20 times in a row:
I get "10 10" ten times and "20 20" ten times.
>
> My "recipe above" was for normal top-level frames. The patch was for
> child frames exclusively. To avoid confusions: The scenario for child
> frames is
>
> (setq my/frame
> (make-frame `((left . 500)
> (top . 5)
> (width . 20)
> (height . 20)
> (parent-frame . ,(selected-frame)))))
>
> (defun my/twiddle (width height)
> (set-frame-size my/frame 10 10)
> (set-frame-size my/frame width height)
> (sit-for 0)
> (message (format "%s %s" (frame-width my/frame) (frame-height my/frame))))
>
> (my/twiddle 20 20)
>
The "(parent-frame . ,(selected-frame))" was not in the recipe you sent a
few hours ago. Amusingly (or not), with that additional frame parameter,
the result is always a 10x10 child frame, and the message always "20 20".
With a (redisplay) or (redisplay t) between the two calls to
set-frame-size the result is always a 20x20 child frame, and the message
always "20 20". With a (sleep-for 0.001) before or between the two calls
to set-frame-size the result is always a 10x10 child frame, and the
message always "20 20".
>
> and my patch fixed that here.
>
It also fixes the above recipe, the one for child frames.
>
> The scenario for normal top-level frames is
>
> (setq my/frame
> (make-frame `((left . 500)
> (top . 5)
> (width . 20)
> (height . 20))))
>
> (defun my/twiddle (width height)
> (set-frame-size my/frame 10 10)
> (set-frame-size my/frame width height)
> (sit-for 0)
> (message (format "%s %s" (frame-width my/frame) (frame-height my/frame))))
>
> (my/twiddle 20 20)
>
> and my patch doesn't do anything about it.
>
Correct, that's what I also see here.
To summarize:
- with the recipe for normal frames, (redisplay) or (redisplay t) between
the two calls to set-frame-size, or (sleep-for 0.001) before the two calls
to set-frame-size, fix the problem (but frame-width and frame-height
return the actual frame width and height only with a 50% probability)
- with the recipe for child frames, your patch, and (redisplay) or
(redisplay t) between the two calls to set-frame-size and without your
patch, fix the problem
This bug report was last modified 1 year and 364 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.