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: martin rudalics <rudalics <at> gmx.at>
To: grischka <grishka <at> gmx.de>
Cc: 1348 <at> debbugs.gnu.org
Subject: bug#1348: set-frame-width and set-frame-position seem buggy on at	least MSWindows
Date: Thu, 27 Nov 2008 20:48:06 +0100

> Why can't it wait?  A couple of frames doesn't sound like thousands
> and also you probably would not start editing your files while your
> frames are still moving around.  So it wouldn't make any difference
> on the user level, except that you'd get correct results by design.

I have never looked into that code.  IIUC one problem is flickering when
a frame gets redrawn too often.  Moreover, it's not always safe to
redraw frames.

> And then it can of course (and probably should) handle other events
> while waiting for the ConfigureNotify.  In GUI apps it is normal that
> "wait" doesn't mean just sleep or block.

Sounds rather like an additional complication.  At the time we call
`set-frame-height' we want to execute Lisp code.

> Btw, on ms-windows such serialization is built-in actually. With
> a call like "SetWindowPos" you'd get the WM_WINDOWPOSCHANGED message
> with the new coordinates and sizes before the call returns.

Isn't this WM_WINDOWPOSCHANGING?  In any case, it seems we still
wouldn't know how many lines the menubar occupies, or am I missing
something?

I'm currently aware of the following bugs WRT frame management on
Windows:

- One can set the frame size only once in a command - that's the bug
  we're talking about here.

- It may take some time to redraw an Emacs frame after removing another
  frame that obscured it (see also Bug#117 and Bug#950).

- All sorts of problems reported by Drew Adams in Bug#117.

Contributions to fix any of these are most welcome ;-)

martin

Previous Next

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