GNU bug report logs -
#1348
set-frame-width and set-frame-position seem buggy on at least MSWindows
Previous Next
Full log
Message #65 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):
> 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
This bug report was last modified 10 years and 296 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.