[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#1348: set-frame-width and set-frame-position seem buggy on at least
From: |
grischka |
Subject: |
bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows |
Date: |
Wed, 03 Dec 2008 01:09:27 +0100 |
User-agent: |
Thunderbird 1.5.0.10 (Windows/20070221) |
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 ...")
- bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows, (continued)
- bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows, martin rudalics, 2008/12/01
- bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows, martin rudalics, 2008/12/02
- bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows, Eli Zaretskii, 2008/12/02
- bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows, martin rudalics, 2008/12/03
- bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows, Eli Zaretskii, 2008/12/03
- bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows, martin rudalics, 2008/12/04
- bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows, grischka, 2008/12/17
- bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows,
grischka <=
- bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows, martin rudalics, 2008/12/03
- bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows, grischka, 2008/12/03
- bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows, Stefan Monnier, 2008/12/03
- bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows, martin rudalics, 2008/12/04
- bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows, grischka, 2008/12/04
- bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows, Eli Zaretskii, 2008/12/05
- bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows, Stefan Monnier, 2008/12/05