GNU bug report logs - #1348
set-frame-width and set-frame-position seem buggy on at least MSWindows

Previous Next

Package: emacs;

Reported by: "Themba Fletcher" <themba <at> shirleymachine.com>

Date: Fri, 14 Nov 2008 22:55:04 UTC

Severity: normal

Done: martin rudalics <rudalics <at> gmx.at>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: grischka <grishka <at> gmx.de>
Cc: jasonr <at> f2s.com, 1348 <at> debbugs.gnu.org
Subject: bug#1348: set-frame-width and set-frame-position seem buggy on at	least MSWindows
Date: Tue, 02 Dec 2008 16:54:11 +0100
> 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

- if a maximize, iconify, restore group request is enqueued we'd drop
  most (or some) of it?

- if another asynchronous (not in the maximize, iconify, restore group)
  size-related request is enqueued, we'd honor it - "instead" of ours?

- if a non-size-related request is in the queue we'd honor it - even it
  has some of our code re-resize frames?

- if there's another frame we don't care about the
  record_asynch_buffer_change (); stuff?

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.