GNU bug report logs - #1348
set-frame-width and set-frame-position seem buggy on at least MSWindows

Previous Next

Full log

View this message in rfc822 format

From: grischka <grishka <at> gmx.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: jasonr <at> f2s.com, 1348 <at> debbugs.gnu.org
Subject: bug#1348: set-frame-width and set-frame-position seem buggy on at	least MSWindows
Date: Fri, 05 Dec 2008 00:24:40 +0100

martin rudalics wrote:
>  > Now not sure what you meant.  Probably something not good.
>  > But what?  Size wrong?  Events lost?  Example?
> 
> Consider the following silly fragment:
> 
> (progn
>   (sleep-for 10)
>   (set-frame-height nil 20))
> 
> C-x C-e it and resize the frame with the WM.  The results here are not
> very predictable, neither with no without your patch.  If you manually
> make the window smaller than 20 lines it gets resized after 10 secs.
> Otherwise it remains larger.  In any case, the point is what gets
> processed by Emacs after the 10 seconds elapsed.

Okay, I could reproduce this (although not the larger/smaller part)

One/The reason is in Fset_frame_height() at frame.c:2695

    if (XINT (lines) != FRAME_LINES (f))
       x_set_window_size (f, 1, FRAME_COLS (f), XINT (lines));

Basically if the window has 20 lines on enter-freeze, then our
thing wouldn't even start, because between "sleep-for" and
"set-frame-height" there is nothing to read the WM_SIZE messages
from the mouse-dragging.

Works for me if I disable this line:
    // if (XINT (lines) ...

It is a natural problem which happens only too often with
such "micro-optimizations".

Next case ?

Previous Next

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