[Top][All Lists]

[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 (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

- 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:
("It doesn't work very well ...")

reply via email to

[Prev in Thread] Current Thread [Next in Thread]