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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 1348 in the body.
You can then email your comments to 1348 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Themba Fletcher" <themba <at> shirleymachine.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: set-frame-width and set-frame-position seem buggy on at least MSWindows
Date: Fri, 14 Nov 2008 17:46:19 -0500

When migrating to Emacs 22.3.1 on microsoft windows, the following
lines in my .emacs file do not behave as expected:

  (set-frame-position (selected-frame) 0 0)
  (sleep-for 2) ; not originally in my .emacs -- testing only
  (set-frame-width (selected-frame) 150)
  (sleep-for 2)
  (set-frame-height (selected-frame) 55)
  (sleep-for 2))

This used to leave me with a 150 X 55 frame located at 0,0 on my
display but it instead now leaves me with a default size frame still
located at 0,0 as expected. Please note that when I said M-x ielm and
pasted in the set-frame-width and -height lines as above after emacs
finished loading they did as I expected, ie. resized the frame
without problem.

I replaced these lines with the following in my .emacs as a
workaround:

(let ((destructo-target (selected-frame)))
  (make-frame (list '(top . 0)
		    '(left . 0)
		    '(width . 150)
		    '(height . 55)))
  (delete-frame destructo-target))


In GNU Emacs 22.3.1 (i386-mingw-nt5.1.2600)
 of 2008-09-06 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Lisp

Minor modes in effect:
  icomplete-mode: t
  partial-completion-mode: t
  encoded-kbd-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<drag-n-drop> M-x l i s p SPC m o d e <tab> <return> 
<wheel-down> <double-wheel-down> <triple-wheel-down> 
<triple-wheel-down> <triple-wheel-down> <wheel-up> 
<double-wheel-up> M-x f i l e SPC b u <tab> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> r e p o r <tab> <return>

Recent messages:
Loading goto-addr...done
top.org has auto save data; consider M-x recover-this-file
Loading c:/Program Files/emacs-22.3/site-lisp/org-6.12b/lisp/org.el
(source)...
Loading easy-mmode...done
Loading derived...done
Loading c:/Program Files/emacs-22.3/site-lisp/org-6.12b/lisp/org.el
(source)...done
OVERVIEW
For information about GNU Emacs and the GNU system, type C-h C-a.
Loading url-util...done
Loading emacsbug...done 

Message #10 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Themba Fletcher <themba <at> shirleymachine.com>,
        1348 <at> debbugs.gnu.org
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at	least MSWindows
Date: Sat, 15 Nov 2008 11:40:39 +0200

> From: "Themba Fletcher" <themba <at> shirleymachine.com>
> Date: Fri, 14 Nov 2008 17:46:19 -0500
> Cc: 
> 
> When migrating to Emacs 22.3.1 on microsoft windows, the following
> lines in my .emacs file do not behave as expected:
> 
>   (set-frame-position (selected-frame) 0 0)
>   (sleep-for 2) ; not originally in my .emacs -- testing only
>   (set-frame-width (selected-frame) 150)
>   (sleep-for 2)
>   (set-frame-height (selected-frame) 55)
>   (sleep-for 2))
                 ^
(Extra paren here.)

> This used to leave me with a 150 X 55 frame located at 0,0 on my
> display but it instead now leaves me with a default size frame still
> located at 0,0 as expected.

This leaves me with a 80x55 frame located at (0,0), not a default size
frame.  I see this both in Emacs 22.3.1 and in the current CVS trunk.

So, while still not entirely correct, the behavior I see is different,
and I wonder why.  Is the above the _only_ contents of your .emacs?

Message #20 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: 1348 <at> debbugs.gnu.org
Cc: themba <at> shirleymachine.com, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on	at	least MSWindows
Date: Sat, 15 Nov 2008 12:04:32 +0200

> Date: Sat, 15 Nov 2008 11:40:39 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: bug-gnu-emacs <at> gnu.org
> 
> This leaves me with a 80x55 frame located at (0,0), not a default size
> frame.  I see this both in Emacs 22.3.1 and in the current CVS trunk.

I think this might be because of the code in
w32term.c:x_set_window_size that was ifdef'ed away to solve a more
grave problem.

Message #30 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 1348 <at> debbugs.gnu.org, themba <at> shirleymachine.com
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy	on
 at	least MSWindows
Date: Sat, 15 Nov 2008 15:12:49 +0100

>> This leaves me with a 80x55 frame located at (0,0), not a default size
>> frame.  I see this both in Emacs 22.3.1 and in the current CVS trunk.
>
> I think this might be because of the code in
> w32term.c:x_set_window_size that was ifdef'ed away to solve a more
> grave problem.

Yes.  But why does `set-frame-height' work after loading .emacs?  The
menubar lines problem can bite whenever we resize a single-frame Emacs.
So what am I missing?

BTW, is this related to Bugs#117 and #201?

martin

Message #35 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: grischka <grishka <at> gmx.de>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at	least MSWindows
Date: Mon, 17 Nov 2008 16:06:48 +0100

> From: "Themba Fletcher"
>
> When migrating to Emacs 22.3.1 on microsoft windows, the following
> lines in my .emacs file do not behave as expected:
>
>   (set-frame-position (selected-frame) 0 0)
>   (sleep-for 2) ; not originally in my .emacs -- testing only
>   (set-frame-width (selected-frame) 150)
>   (sleep-for 2)
>   (set-frame-height (selected-frame) 55)
>   (sleep-for 2))
>

Actually it doesn't work on X/GTK either.

Message #40 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Themba Fletcher" <themba <at> shirleymachine.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: <bug-gnu-emacs <at> gnu.org>
Subject: RE: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows
Date: Mon, 17 Nov 2008 15:50:06 -0500

[Message part 1 (text/plain, inline)]

> From: Eli Zaretskii [mailto:eliz <at> gnu.org] 
> Sent: Saturday, November 15, 2008 4:41 AM
> To: Themba Fletcher; 1348 <at> emacsbugs.donarmstrong.com
> Cc: bug-gnu-emacs <at> gnu.org

> > From: "Themba Fletcher" <themba <at> shirleymachine.com>
> > Date: Fri, 14 Nov 2008 17:46:19 -0500
> > Cc: 

> > When migrating to Emacs 22.3.1 on microsoft windows, the following
> > lines in my .emacs file do not behave as expected:

> >   (set-frame-position (selected-frame) 0 0)
> >   (sleep-for 2) ; not originally in my .emacs -- testing only
> >   (set-frame-width (selected-frame) 150)
> >   (sleep-for 2)
> >   (set-frame-height (selected-frame) 55)
> >   (sleep-for 2))

> (Extra paren here^)

Whoops, this was nested in an expression while I was testing.

> > This used to leave me with a 150 X 55 frame located at 0,0 on my
> > display but it instead now leaves me with a default size frame still
> > located at 0,0 as expected.

> This leaves me with a 80x55 frame located at (0,0), not a default size
> frame.  I see this both in Emacs 22.3.1 and in the current CVS trunk.

> So, while still not entirely correct, the behavior I see is different,
> and I wonder why.  Is the above the _only_ contents of your .emacs?

No, but the behavior held even when the rest of my .emacs was commented out.
Please feel free to play with my original .emacs file, attached.

I was upgrading, due to standard windows problems (ie I had to reformat and
reinstall), from Emacs 22.1 when I found this. Over the weekend I moved my
home machine from Emacs 22.2 to 22.3 and discovered two things:

1. The bug is present in 22.2
2. (set-frame-size) is not affected, and is probably a better work-around
than I gave in my previous message.

[dot-emacs (application/octet-stream, attachment)]

Message #45 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Themba Fletcher <themba <at> shirleymachine.com>
Cc: 1348 <at> debbugs.gnu.org, "'Eli Zaretskii'" <eliz <at> gnu.org>
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at	least MSWindows
Date: Tue, 18 Nov 2008 14:03:27 +0100

[Message part 1 (text/plain, inline)]

>>> When migrating to Emacs 22.3.1 on microsoft windows, the following
>>> lines in my .emacs file do not behave as expected:
>
>>>   (set-frame-position (selected-frame) 0 0)
>>>   (sleep-for 2) ; not originally in my .emacs -- testing only
>>>   (set-frame-width (selected-frame) 150)
>>>   (sleep-for 2)
>>>   (set-frame-height (selected-frame) 55)
>>>   (sleep-for 2))
[...]
> 1. The bug is present in 22.2
> 2. (set-frame-size) is not affected, and is probably a better work-around
> than I gave in my previous message.

Interesting.  Does the attached patch give better results?

martin

[dispnew.diff (text/plain, inline)]

*** dispnew.c.~1.424.~	2008-10-28 07:22:51.656250000 +0100
--- dispnew.c	2008-11-18 13:57:27.546875000 +0100
***************
*** 6305,6310 ****
--- 6305,6316 ----
    int new_frame_total_cols;
    int count = SPECPDL_INDEX ();
  
+   /* If an argument is zero, set it to the current value.  */
+   if (newheight == 0)
+     newheight = FRAME_LINES (f);
+   if (newwidth == 0)
+     newwidth  = FRAME_COLS  (f);
+ 
    /* If we can't deal with the change now, queue it for later.  */
    if (delay || (redisplaying_p && !safe))
      {
***************
*** 6318,6329 ****
    f->new_text_lines = 0;
    f->new_text_cols = 0;
  
-   /* If an argument is zero, set it to the current value.  */
-   if (newheight == 0)
-     newheight = FRAME_LINES (f);
-   if (newwidth == 0)
-     newwidth  = FRAME_COLS  (f);
- 
    /* Compute width of windows in F.
       This is the width of the frame without vertical scroll bars.  */
    new_frame_total_cols = FRAME_TOTAL_COLS_ARG (f, newwidth);
--- 6324,6329 ----

Message #50 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: grischka <grishka <at> gmx.de>
To: 1348 <at> debbugs.gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at least MSWindows
Date: Wed, 26 Nov 2008 22:22:20 +0100

martin rudalics wrote:

> Interesting.  Does the attached patch give better results?

Why waste time with looking for "better results" instead of a
correct solution?

Which is obviously that these set-frame-xxx functions need to wait
for the ConfigureNotify event and to handle it before they return.

Message #55 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: grischka <grishka <at> gmx.de>, 1348 <at> debbugs.gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at	least MSWindows
Date: Thu, 27 Nov 2008 14:41:36 +0100

> Why waste time with looking for "better results" instead of a
> correct solution?
>
> Which is obviously that these set-frame-xxx functions need to wait
> for the ConfigureNotify event and to handle it before they return.

I doubt such a solution would be generally feasible.  A command might
try to set the height and width of a couple of frames.  It can't wait
for a ConfigureNotify event to arrive for each of these.

martin

Message #60 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: grischka <grishka <at> gmx.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 1348 <at> debbugs.gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at	least MSWindows
Date: Thu, 27 Nov 2008 18:45:45 +0100

martin rudalics wrote:
>  > Why waste time with looking for "better results" instead of a
>  > correct solution?
>  >
>  > Which is obviously that these set-frame-xxx functions need to wait
>  > for the ConfigureNotify event and to handle it before they return.
> 
> I doubt such a solution would be generally feasible.  A command might
> try to set the height and width of a couple of frames.  It can't wait
> for a ConfigureNotify event to arrive for each of these.

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.

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.

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.

Message #65 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: grischka <grishka <at> gmx.de>
Cc: 1348 <at> debbugs.gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at	least MSWindows
Date: Thu, 27 Nov 2008 20:48:06 +0100

> 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

Message #70 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: grischka <grishka <at> gmx.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 1348 <at> debbugs.gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at	least MSWindows
Date: Sat, 29 Nov 2008 20:42:38 +0100

martin rudalics wrote:

>  > 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.

Redraw? Isn't this about resize rather than redraw?

>  > 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.

Complication is not additional if it allows you to get rid of other
complication, in particular such that causes inexplicable misbehavior.

> ... In any case, it seems we still
> wouldn't know how many lines the menubar occupies, or am I missing
> something?

Well, whatever the answer to this question is, I'm afraid it wouldn't
help to understand the bug.  It happens with no menubar as well.

Message #75 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: grischka <grishka <at> gmx.de>
Cc: 1348 <at> debbugs.gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at	least MSWindows
Date: Sun, 30 Nov 2008 10:19:38 +0100

>> 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.
>
> Redraw? Isn't this about resize rather than redraw?

You can, in one command, issue a number of resize requests.  I doubt we
want each of them cause a redisplay/redraw before the command completes.

>> ... In any case, it seems we still
>> wouldn't know how many lines the menubar occupies, or am I missing
>> something?
>
> Well, whatever the answer to this question is, I'm afraid it wouldn't
> help to understand the bug.  It happens with no menubar as well.

The wrapping menubar problem is one of the w32 API - it's nothing we can
do about.  Personally, I considered Jason's reaction too drastic.  So
maybe we should make it conditional on the presence of a menubar.  Also,
I see other applications truncate the menubar in a similar situation.

Anyway - I don't have much of an idea what to do here.  If you can
provide any patches I'll be happy to test them.

martin

Message #80 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: grischka <grishka <at> gmx.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 1348 <at> debbugs.gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at	least MSWindows
Date: Sun, 30 Nov 2008 18:40:15 +0100

martin rudalics wrote:

>  >> 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.
>  >
>  > Redraw? Isn't this about resize rather than redraw?
> 
> You can, in one command, issue a number of resize requests.  I doubt we
> want each of them cause a redisplay/redraw before the command completes.

But who said anything about redisplay/redraw?  What it needs to
wait for is the notification from the window system or toolkit
that the resize request was carried out.

Otherwise emacs runs into situations where the state of it's
internal variables w.r.t. frame size/position is not consistent
with the state of the GUI, and in consequence the inconsistent
GUI state works back on these variables.  (by means of the logic
meant for mouse sizing/dragging)

I guess that is the basic problem. There may be additional aspects
like toolkit differences or race conditions.

Message #85 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: grischka <grishka <at> gmx.de>
Cc: 1348 <at> debbugs.gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at	least MSWindows
Date: Sun, 30 Nov 2008 21:02:19 +0100

> But who said anything about redisplay/redraw?  What it needs to
> wait for is the notification from the window system or toolkit
> that the resize request was carried out.

The WM_WINDOWPOSCHANGED message is sent after the window is shown
(redisplayed, redrawn, ...).

martin

Message #90 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: grischka <grishka <at> gmx.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 1348 <at> debbugs.gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at	least MSWindows
Date: Sun, 30 Nov 2008 23:04:45 +0100

martin rudalics wrote:
>  > But who said anything about redisplay/redraw?  What it needs to
>  > wait for is the notification from the window system or toolkit
>  > that the resize request was carried out.
> 
> The WM_WINDOWPOSCHANGED message is sent after the window is shown
> (redisplayed, redrawn, ...).
> 
> martin
> 

How this? Say if I click the "maximise" button, you think that
emacs first redraws itself and later then sets the new row/col
count?

Message #95 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: grischka <grishka <at> gmx.de>
Cc: 1348 <at> debbugs.gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at	least MSWindows
Date: Sun, 30 Nov 2008 23:50:45 +0100

>>  > But who said anything about redisplay/redraw?  What it needs to
>>  > wait for is the notification from the window system or toolkit
>>  > that the resize request was carried out.
>>
>> The WM_WINDOWPOSCHANGED message is sent after the window is shown
>> (redisplayed, redrawn, ...).
>>
> How this? Say if I click the "maximise" button, you think that
> emacs first redraws itself and later then sets the new row/col
> count?

I don't.  But how does this relate to what I said above?  It's
one thing what Emacs does by itself and another thing what it's
asked to do.

martin

Message #100 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: grischka <grishka <at> gmx.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 1348 <at> debbugs.gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at	least MSWindows
Date: Mon, 01 Dec 2008 00:08:28 +0100

martin rudalics wrote:
> ... It's
> one thing what Emacs does by itself and another thing what it's
> asked to do.

We know that.  That's why people write bug reports.

Message #105 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: jasonr <at> f2s.com
To: martin rudalics <rudalics <at> gmx.at>, 1348 <at> debbugs.gnu.org
Cc: grischka <grishka <at> gmx.de>
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on	at	least MSWindows
Date: Sun, 30 Nov 2008 23:54:24 +0000

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

> The wrapping menubar problem is one of the w32 API - it's nothing we can
> do about.  Personally, I considered Jason's reaction too drastic.

Please explain. This is my first contribution to this thread, so obviously you
are talking about something in the distant past which my memory cannot recall.

Message #110 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: jasonr <at> f2s.com
Cc: 1348 <at> debbugs.gnu.org, grischka <grishka <at> gmx.de>
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at	least MSWindows
Date: Mon, 01 Dec 2008 08:28:00 +0100

>> The wrapping menubar problem is one of the w32 API - it's nothing we can
>> do about.  Personally, I considered Jason's reaction too drastic.
>
> Please explain. This is my first contribution to this thread, so obviously you
> are talking about something in the distant past which my memory cannot recall.

As Eli explained earlier, this thread is a consequence of your change

2007-10-09  Jason Rumney  <jasonr <at> gnu.org>

	* w32term.c (x_set_window_size): Disable code that attempts to tell
	Lisp code about a size change before it actually happens.

which causes, according to the OP, a sequence of frame changes like

  (set-frame-position (selected-frame) 0 0)
  (sleep-for 2) ; not originally in my .emacs -- testing only
  (set-frame-width (selected-frame) 150)
  (sleep-for 2)
  (set-frame-height (selected-frame) 55)
  (sleep-for 2))

to virtually do the first operation only.  According to grischka
something similar happens on X/GTK as well, but he never told us what he
sees there.

IIUC your change is motivated as

  /* The following mirrors what is done in xterm.c. It appears to be
     for informing lisp of the new size immediately, while the actual
     resize will happen asynchronously. But on Windows, the menu bar
     automatically wraps when the frame is too narrow to contain it,
     and that causes any calculations made here to come out wrong. The
     end is some nasty buggy behavior, including the potential loss
     of the minibuffer.

     Disabling this code is either not sufficient to fix the problems
     completely, or it causes fresh problems, but at least it removes
     the most problematic symptom of the minibuffer becoming unusable.

     [...]
  */

Given that wrapping menubars are not very frequent, it seems to me that
by now the "fresh problems" outweigh the "menubar problem", but YMMV.

martin

Message #115 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: jasonr <at> f2s.com
To: martin rudalics <rudalics <at> gmx.at>
Cc: 1348 <at> debbugs.gnu.org, grischka <grishka <at> gmx.de>
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at	least MSWindows
Date: Mon,  1 Dec 2008 08:22:17 +0000

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

> IIUC your change is motivated as
>
>       Disabling this code is either not sufficient to fix the problems
>       completely, or it causes fresh problems, but at least it removes
>       the most problematic symptom of the minibuffer becoming unusable.
>
> Given that wrapping menubars are not very frequent, it seems to me that
> by now the "fresh problems" outweigh the "menubar problem", but YMMV.

Which of the fresh problems outweighs an unusable minibuffer?

Message #120 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: jasonr <at> f2s.com
Cc: 1348 <at> debbugs.gnu.org, grischka <grishka <at> gmx.de>
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at	least MSWindows
Date: Mon, 01 Dec 2008 10:34:29 +0100

> Which of the fresh problems outweighs an unusable minibuffer?

The one that a resize request has no effect.  But as I stated before
that's just my personal opinion.

martin

Message #125 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

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

########################################
--- w32term-old.c       Mon Dec 01 17:50:28 2008
+++ w32term.c   Tue Dec 02 06:21:48 2008
@@ -4519,6 +4519,7 @@ w32_read_socket (sd, expected, hold_quit
           f = x_window_to_frame (dpyinfo, msg.msg.hwnd);

           /* Inform lisp of whether frame has been iconified etc. */
+          if (-100 != sd)
           if (f)
             {
               switch (msg.msg.wParam)
@@ -5384,6 +5385,7 @@ x_set_offset (f, xoff, yoff, change_grav
                      0, 0,
                      SWP_NOZORDER | SWP_NOSIZE | SWP_NOACTIVATE);
   UNBLOCK_INPUT;
+  w32_read_socket(-100, 0, NULL);
 }


@@ -5509,6 +5511,7 @@ x_set_window_size (f, change_gravity, co
 #endif

   UNBLOCK_INPUT;
+  w32_read_socket(-100, 0, NULL);
 }
 
 /* Mouse warping.  */
########################################

Message #130 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: jasonr <at> f2s.com
To: grischka <grishka <at> gmx.de>, 1348 <at> debbugs.gnu.org
Cc: martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on	at	least MSWindows
Date: Tue,  2 Dec 2008 07:42:43 +0000

Quoting grischka <grishka <at> gmx.de>:

> Below is a patch that fixes the problem on windows.

I believe this patch is incorrect, as it will result in the message handling
code running in the context of the Lisp thread, which will result in a whole
host of unreproducable crashing bugs if left like that. Probably the reason it
seems to work is that it introduces a delay that is generally long enough for
the real resizing or moving to take place before the Lisp thread continues.

Inter-thread synchronization is what is needed here to fix this safely and
deterministically.

Message #135 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

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

jasonr wrote:
> Quoting grischka:
> 
>> Below is a patch that fixes the problem on windows.
> 
> I believe this patch is incorrect, as it will result in the message handling
> code running in the context of the Lisp thread, which will result in a whole
> host of unreproducable crashing bugs if left like that. Probably the reason it
> seems to work is that it introduces a delay that is generally long enough for
> the real resizing or moving to take place before the Lisp thread continues.

Believes are not an approach to code, coincidentally none of the above
do apply.

> Inter-thread synchronization is what is needed here to fix this safely and
> deterministically.

Nicely put.  This is the theory.

(As to practical things that need fixing:

  HRGN orig_clip;
  GetClipRgn(s->hdc, orig_clip);

Or:

  for (i = 0; i < len; i++)
    ExtTextOutW (s->hdc, x + i, y, options, NULL,
      s->char2b + from + i, 1, NULL);
)

Message #140 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: grischka <grishka <at> gmx.de>
Cc: jasonr <at> f2s.com, 1348 <at> debbugs.gnu.org
Subject: Re: 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

Message #145 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>, 1348 <at> debbugs.gnu.org
Cc: grishka <at> gmx.de, jasonr <at> f2s.com, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on	at	least MSWindows
Date: Tue, 02 Dec 2008 22:04:46 +0200

> Date: Tue, 02 Dec 2008 16:54:11 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: 1348 <at> emacsbugs.donarmstrong.com, jasonr <at> f2s.com
> 
>  > 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

I'd advise against it: as Jason wrote, that patch mixes two different
threads, which is asking for trouble.  It'd be a pity to waste your
valuable time on using and debugging incorrect code.

Message #155 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: grischka <grishka <at> gmx.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: jasonr <at> f2s.com, 1348 <at> debbugs.gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at	least MSWindows
Date: Wed, 03 Dec 2008 01:09:27 +0100

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 ...")

Message #160 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 1348 <at> debbugs.gnu.org, grishka <at> gmx.de, jasonr <at> f2s.com,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at least MSWindows
Date: Wed, 03 Dec 2008 11:17:13 +0100

> I'd advise against it: as Jason wrote, that patch mixes two different
> threads, which is asking for trouble.  It'd be a pity to waste your
> valuable time on using and debugging incorrect code.

I understand.  But earlier I stated that I would test proposed patches,
so that's what I'm doing now.  If we think that grischka's patch is
wrong, we should be able to give an (at least hypothetical) example why.

martin

Message #170 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: grischka <grishka <at> gmx.de>
Cc: jasonr <at> f2s.com, 1348 <at> debbugs.gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at	least MSWindows
Date: Wed, 03 Dec 2008 11:17:28 +0100

> Actually -100 doesn't mean anything except to let the "async_visible"
> flag alone, because otherwise no frame showed at all, for some reason.

But your patch skips more than just the async_visible assignments.

>> - 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.

Not really, because the current code doesn't call w32_read_socket until
input gets unblocked.

>> - 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?

I suppose resizing a frame might do all sorts of nasty things like
resizing and deleting windows within the resized frame, switching
buffers, showing another menu-/tool-bar, ...

martin

Message #175 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: grischka <grishka <at> gmx.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: jasonr <at> f2s.com, 1348 <at> debbugs.gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at	least MSWindows
Date: Wed, 03 Dec 2008 18:24:54 +0100

martin rudalics wrote:

>  > Actually -100 doesn't mean anything except to let the "async_visible"
>  > flag alone, because otherwise no frame showed at all, for some reason.
> 
> But your patch skips more than just the async_visible assignments.

Saved me one line to type.  Anyway, I found the reason:

     case SIZE_MAXIMIZED:
     case SIZE_RESTORED:
        f->async_visible = 1;

Basically RESTORED or MAXIMIZED don't necessarily mean visible in the
windows sense.  I replaced it with

	f->async_visible = IsWindowVisible(msg.msg.hwnd) ? 1 : 0;

I also replaced w32_read_socket() by a less suspicious looking

	gobble_input (0);

I'm not so into emacs internals to tell whether this is the
finally ideal function to use.  You might know better.

>  >> - 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.
> 
> Not really, because the current code doesn't call w32_read_socket until
> input gets unblocked.

Now not sure what you meant.  Probably something not good.
But what?  Size wrong?  Events lost?  Example?

>  >> - 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?
> 
> I suppose resizing a frame might do all sorts of nasty things like
> resizing and deleting windows within the resized frame, switching
> buffers, showing another menu-/tool-bar, ...

Only with at least two frames?  Sounds cryptic ;)

> 
> martin
> 

New patch:

########################################
--- w32term-old.c       Mon Dec 01 17:50:28 2008
+++ w32term.c   Wed Dec 03 17:39:21 2008
@@ -4533,7 +4533,7 @@ w32_read_socket (sd, expected, hold_quit

                 case SIZE_MAXIMIZED:
                 case SIZE_RESTORED:
-                  f->async_visible = 1;
+                  f->async_visible = IsWindowVisible(msg.msg.hwnd) ? 1 : 0;
                   f->async_iconified = 0;

                   /* wait_reading_process_output will notice this and update
@@ -5384,6 +5384,7 @@ x_set_offset (f, xoff, yoff, change_grav
                      0, 0,
                      SWP_NOZORDER | SWP_NOSIZE | SWP_NOACTIVATE);
   UNBLOCK_INPUT;
+  gobble_input (0);
 }


@@ -5509,6 +5510,7 @@ x_set_window_size (f, change_gravity, co
 #endif

   UNBLOCK_INPUT;
+  gobble_input (0);
 }
 
 /* Mouse warping.  */
########################################

Message #180 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 1348 <at> debbugs.gnu.org, grishka <at> gmx.de, jasonr <at> f2s.com,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows
Date: Wed, 03 Dec 2008 20:32:50 +0200

> Date: Wed, 03 Dec 2008 11:17:13 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 1348 <at> emacsbugs.donarmstrong.com, grishka <at> gmx.de, jasonr <at> f2s.com, 
>  bug-gnu-emacs <at> gnu.org
> 
> If we think that grischka's patch is wrong, we should be able to
> give an (at least hypothetical) example why.

I don't see a need for giving an example for something that is so
blatantly wrong: it calls one thread's code from within another.
Since the Emacs input thread was written _specifically_ to overcome
problems with delivering input asynchronously, it should be clear to
anyone that mixing such threads is dead wrong, period.

Message #190 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: grischka <grishka <at> gmx.de>
Cc: 1348 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>,
        jasonr <at> f2s.com
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at	least MSWindows
Date: Wed, 03 Dec 2008 16:41:04 -0500

>   f-> async_visible = IsWindowVisible(msg.msg.hwnd) ? 1 : 0;

This is an eta-expression (See
http://en.wikipedia.org/wiki/Lambda_calculus#.CE.B7-conversion although
it only talks about the case of eta for functions rather than for
booleans), so you should probably rewrite it as

   f-> async_visible = IsWindowVisible(msg.msg.hwnd);


-- Stefan

Message #195 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: grischka <grishka <at> gmx.de>
To: eliz <at> gnu.org
Cc: 1348 <at> debbugs.gnu.org, jasonr <at> f2s.com,
        martin rudalics <rudalics <at> gmx.at>
Subject: bug#1348: set-frame-width and set-frame-position seem buggy on at
 least MSWindows
Date: Wed, 03 Dec 2008 22:43:27 +0100

Eli Zaretskii wrote:

> I don't see a need for giving an example for something that is so
> blatantly wrong: it calls one thread's code from within another.
> Since the Emacs input thread was written _specifically_ to overcome
> problems with delivering input asynchronously, it should be clear to
> anyone that mixing such threads is dead wrong, period.

Clear to anyone who? Doesn't see a need or is able to read?

Actually,
	w32_read_socket()
calls
	change_frame_size() at w32term:4596
which finally calls
	run_window_configuration_change_hook() at dispnew:6414
which runs lisp code.

You will maybe agree that it makes sense to run this hook as
a consequence from a lisp call to "set-frame-width".

Message #200 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: grischka <grishka <at> gmx.de>
Cc: 1348 <at> debbugs.gnu.org, jasonr <at> f2s.com, rudalics <at> gmx.at
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows
Date: Thu, 04 Dec 2008 06:07:53 +0200

> Date: Wed, 03 Dec 2008 22:43:27 +0100
> From: grischka <grishka <at> gmx.de>
> CC:  1348 <at> emacsbugs.donarmstrong.com,  jasonr <at> f2s.com, 
>  martin rudalics <rudalics <at> gmx.at>
> 
> You will maybe agree that it makes sense to run this hook as
> a consequence from a lisp call to "set-frame-width".

No, I don't agree.  In Emacs, Lisp calls don't call redisplay
directly.  They change variables and objects that affect the next
redisplay.  Redisplay itself is triggered by other events.  Any change
that doesn't follow this pattern is wrong.

Message #205 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: grischka <grishka <at> gmx.de>
Cc: jasonr <at> f2s.com, 1348 <at> debbugs.gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at	least MSWindows
Date: Thu, 04 Dec 2008 18:58:52 +0100

> Now not sure what you meant.  Probably something not good.
> But what?  Size wrong?  Events lost?  Example?

Consider the following silly fragment:

(progn
  (sleep-for 10)
  (set-frame-height nil 20))

C-x C-e it and resize the frame with the WM.  The results here are not
very predictable, neither with no without your patch.  If you manually
make the window smaller than 20 lines it gets resized after 10 secs.
Otherwise it remains larger.  In any case, the point is what gets
processed by Emacs after the 10 seconds elapsed.

>> I suppose resizing a frame might do all sorts of nasty things like
>> resizing and deleting windows within the resized frame, switching
>> buffers, showing another menu-/tool-bar, ...
>
> Only with at least two frames?  Sounds cryptic ;)

With one frame.  Emacs reacts to frame resizing requests by adjusting
the windows within the frame accordingly.  If a window gets too small,
Emacs has to delete one (note that Emacs implements a tiling window
manager within each frame).  Eventually, all that remains is the menubar
or, if there's none, just the title line.  And, deleting a window may
change the menubar because another buffer may become current.

martin

Message #210 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 1348 <at> debbugs.gnu.org, grishka <at> gmx.de, jasonr <at> f2s.com
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at least MSWindows
Date: Thu, 04 Dec 2008 19:00:25 +0100

> I don't see a need for giving an example for something that is so
> blatantly wrong: it calls one thread's code from within another.
> Since the Emacs input thread was written _specifically_ to overcome
> problems with delivering input asynchronously, it should be clear to
> anyone that mixing such threads is dead wrong, period.

I can only _speculate_ on how Emacs is supposed to handle a frame size
change requested by a Lisp routine.

(1) Calculate (and internally store) the new size and send the WM
    (window manager) an appropriate request.

(2) Continue the calling routine with the size calculated in (1).

(3) When the WM confirmation finally arrives treat it as a resize
    request initiated by the WM.

The idea seems that the sizes calculated in (1) and the size request in
(3) coincide and no further resizing is necessary thereafter.

Apparently Jason changed (1) on Windows in the sense that it does not
internally store the new size.  So if a Lisp routine issues another
resize request before (3) is handled, (1) starts calculations with the
values as they were before the Lisp routine started.  The request that
eventually gets processed by the Windows WM is the last
resize/positioning request issued by the Lisp routine, with the values
valid before the Lisp routine started.

Now grischka's proposal seems to wait for the WM's confirmation within
(1), that is embed (3) in (1), and have (2) proceed with the values
promised (or confirmed) by the WM.  This apparently runs counter to the
ideology that the processing of asynchronous input should not happen in
certain occasions and apparently a step like (1) is one of these.

So the first thing we'd have to agree upon is whether we want a function
like `set-frame-height' process messages of the WM.  If we don't want
that, we have to find another way to make `set-frame-height' DTRT which
seems non-trivial to me.

If we want that, we have to decide how to synchronize the handling of a
confirmation message with the rest of system messages arriving around
that time.  For this purpose, we have to determine what can be safely
processed and what must be processed to ensure liveness while waiting
for the confirmation.  (I suppose that's what Jason's "inter-thread
synchronization" amounts to, though I don't understand the term "thread"
in the present context - sorry.  But maybe that's what ATTACH_THREADS
was about.)

Till we agree on something here I can test grischka's patches to know
whether his approach can handle the problem at all - that is whether the
confirmation gets through and is handled.

martin

Message #215 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: grischka <grishka <at> gmx.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: jasonr <at> f2s.com, 1348 <at> debbugs.gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at	least MSWindows
Date: Fri, 05 Dec 2008 00:24:40 +0100

martin rudalics wrote:
>  > Now not sure what you meant.  Probably something not good.
>  > But what?  Size wrong?  Events lost?  Example?
> 
> Consider the following silly fragment:
> 
> (progn
>   (sleep-for 10)
>   (set-frame-height nil 20))
> 
> C-x C-e it and resize the frame with the WM.  The results here are not
> very predictable, neither with no without your patch.  If you manually
> make the window smaller than 20 lines it gets resized after 10 secs.
> Otherwise it remains larger.  In any case, the point is what gets
> processed by Emacs after the 10 seconds elapsed.

Okay, I could reproduce this (although not the larger/smaller part)

One/The reason is in Fset_frame_height() at frame.c:2695

    if (XINT (lines) != FRAME_LINES (f))
       x_set_window_size (f, 1, FRAME_COLS (f), XINT (lines));

Basically if the window has 20 lines on enter-freeze, then our
thing wouldn't even start, because between "sleep-for" and
"set-frame-height" there is nothing to read the WM_SIZE messages
from the mouse-dragging.

Works for me if I disable this line:
    // if (XINT (lines) ...

It is a natural problem which happens only too often with
such "micro-optimizations".

Next case ?

Message #220 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: grischka <grishka <at> gmx.de>, 1348 <at> debbugs.gnu.org
Cc: rudalics <at> gmx.at, jasonr <at> f2s.com, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on	at	least MSWindows
Date: Fri, 05 Dec 2008 08:20:04 +0200

> Date: Fri, 05 Dec 2008 00:24:40 +0100
> From: grischka <grishka <at> gmx.de>
> Cc: 1348 <at> emacsbugs.donarmstrong.com, jasonr <at> f2s.com
> 
>      if (XINT (lines) != FRAME_LINES (f))
>         x_set_window_size (f, 1, FRAME_COLS (f), XINT (lines));
> 
> Basically if the window has 20 lines on enter-freeze, then our
> thing wouldn't even start, because between "sleep-for" and
> "set-frame-height" there is nothing to read the WM_SIZE messages
> from the mouse-dragging.
> 
> Works for me if I disable this line:
>      // if (XINT (lines) ...
> 
> It is a natural problem which happens only too often with
> such "micro-optimizations".

This is not a "micro-optimization".  Emacs deliberately avoids
unnecessary calls to display routines, because frequent redisplay that
doesn't really change anything causes flickering that is quite
annoying.  Therefore, your "solution" is wrong.

Message #230 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 1348 <at> debbugs.gnu.org, grischka <grishka <at> gmx.de>,
        bug-gnu-emacs <at> gnu.org, jasonr <at> f2s.com
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on	at	least MSWindows
Date: Fri, 05 Dec 2008 10:58:37 -0500

>> if (XINT (lines) != FRAME_LINES (f))
>> x_set_window_size (f, 1, FRAME_COLS (f), XINT (lines));
>> 
>> Basically if the window has 20 lines on enter-freeze, then our
>> thing wouldn't even start, because between "sleep-for" and
>> "set-frame-height" there is nothing to read the WM_SIZE messages
>> from the mouse-dragging.
>> 
>> Works for me if I disable this line:
>> // if (XINT (lines) ...
>> 
>> It is a natural problem which happens only too often with
>> such "micro-optimizations".

> This is not a "micro-optimization".  Emacs deliberately avoids
> unnecessary calls to display routines, because frequent redisplay that
> doesn't really change anything causes flickering that is quite
> annoying.  Therefore, your "solution" is wrong.

Maybe it's not the right fix, but since it appears to fix the original
problem, we should look into why it fixes the problem.


        Stefan

Message #240 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: grischka <grishka <at> gmx.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 1348 <at> debbugs.gnu.org,
        jasonr <at> f2s.com
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at least MSWindows
Date: Tue, 16 Dec 2008 18:11:42 +0100

martin rudalics wrote:
> ...
> If we want that, we have to decide how to synchronize the handling of a
> confirmation message with the rest of system messages arriving around
> that time.  For this purpose, we have to determine what can be safely
> processed and what must be processed to ensure liveness while waiting
> for the confirmation.  (I suppose that's what Jason's "inter-thread
> synchronization" amounts to, though I don't understand the term "thread"
> in the present context - sorry.  But maybe that's what ATTACH_THREADS
> was about.)

Note that the suggested patch handles all that perfectly well.  Doing
anything in addition like what you mention above is unnecessary, in
fact likely contra-productive.

Instead I'd suggest to look into the X and GTK part of this issue
(frame-positioning/resizing that is) now.  On that platforms it is
still broken in several aspects and considerations are spent much more
usefully there.

Then after having fixed X and GTK you can still come back to Windows
and try to do better than the suggested 3-line patch.  Maybe you can,
who knows.

Message #245 received at 1348-done <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: 1348-done <at> debbugs.gnu.org
Subject: Re: set-frame-width and set-frame-position seem buggy on at least
 MSWindows
Date: Sun, 21 Sep 2014 20:02:05 +0200

> When migrating to Emacs 22.3.1 on microsoft windows, the following
> lines in my .emacs file do not behave as expected:
>
>   (set-frame-position (selected-frame) 0 0)
>   (sleep-for 2) ; not originally in my .emacs -- testing only
>   (set-frame-width (selected-frame) 150)
>   (sleep-for 2)
>   (set-frame-height (selected-frame) 55)
>   (sleep-for 2))
>
> This used to leave me with a 150 X 55 frame located at 0,0 on my
> display but it instead now leaves me with a default size frame still
> located at 0,0 as expected. Please note that when I said M-x ielm and
> pasted in the set-frame-width and -height lines as above after emacs
> finished loading they did as I expected, ie. resized the frame
> without problem.

Should work in emacs-24 as intended.  Closing this bug.

Thanks, martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.