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
martin rudalics wrote:
> > Below is a patch that fixes the problem on windows.
> >
> > As to X, it turned out that there is actually something
> > similar, it calls itself "x_sync_with_move".
> >
> > Have fun.
>
> Thanks. I'm running Emacs now with your patch and will inform you if
> and when I find any problems. But please be a bit less cryptic, at
> least when talking to illiterate people like me ;-)
>
> > + if (-100 != sd)
> [....]
> > + w32_read_socket(-100, 0, NULL);
>
> I suppose the -100 means to not handle "some" asynchronous resize
> requests while the WM handles ours. So
>
Actually -100 doesn't mean anything except to let the "async_visible"
flag alone, because otherwise no frame showed at all, for some reason.
(okay, that WAS cryptic)
> - if a maximize, iconify, restore group request is enqueued we'd drop
> most (or some) of it?
>
No, nothing is dropped.
> - if another asynchronous (not in the maximize, iconify, restore group)
> size-related request is enqueued, we'd honor it - "instead" of ours?
>
There is no "instead" with a queue. What's in comes out, sooner or
later.
> - if a non-size-related request is in the queue we'd honor it - even it
> has some of our code re-resize frames?
>
Sure, as always.
> - if there's another frame we don't care about the
> record_asynch_buffer_change (); stuff?
>
What buffer change? Resize doesn't change buffers, does it?
Btw, here is another incarnation of the issue:
http://lists.gnu.org/archive/html/help-gnu-emacs/2008-12/msg00034.html
("It doesn't work very well ...")
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.