bug#23320: 25.0.92; Window width not updated after frame resize (Win32 and GTK)

bug#23320: 25.0.92; Window width not updated after frame resize (Win32 and GTK)

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 3140 bytes --]

Hi!

I noticed a regression on 25.0.92 compared to 24.5 where the following code
behaves differently on the w32 port. (On a recent GTK build it also
misbehaves, but not under the NS port.)

    (progn
      (set-frame-size (selected-frame) 1000 400 t)
      (window-width nil t))

On 24.5, this evaluates to "1000". However, on 25.0.92 `window-width'
returns the width prior to the frame resize. (Evaluating it a second time
returns 1000, though.)

Adding `(sit-for 0)' before the call to `window-width' make is return 1000
the first time, but it doesn't feel like a robust solution.

Is this the expected behavior? If it is, is adding `(sit-for 0)' the
recommended way to get the correct window width after a frame resize?

    -- Anders Lindgren


In GNU Emacs 25.0.92.1 (i686-w64-mingw32)
 of 2016-03-21 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Configured using:
 'configure --host=i686-w64-mingw32 --without-dbus
 --without-compress-install CFLAGS=-static'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: SVE
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec epg epg-config gnus-util mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util help-fns help-mode easymenu cl-loaddefs pcase
cl-lib mail-prsvr mail-utils time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp
disp-table w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote w32notify w32 multi-tty
make-network-process emacs)

Memory information:
((conses 8 89463 5796)
 (symbols 32 19588 0)
 (miscs 32 44 151)
 (strings 16 15873 4098)
 (string-bytes 1 434746)
 (vectors 8 12347)
 (vector-slots 4 429150 3960)
 (floats 8 165 156)
 (intervals 28 259 49)
 (buffers 520 12))

[-- Attachment #2: Type: text/html, Size: 4454 bytes --]

bug#23320: 25.0.92; Window width not updated after frame resize (Win32 and GTK)

[martin rudalics]

 > I noticed a regression on 25.0.92 compared to 24.5 where the following code
 > behaves differently on the w32 port. (On a recent GTK build it also
 > misbehaves, but not under the NS port.)
 >
 >      (progn
 >        (set-frame-size (selected-frame) 1000 400 t)
 >        (window-width nil t))
 >
 > On 24.5, this evaluates to "1000". However, on 25.0.92 `window-width'
 > returns the width prior to the frame resize. (Evaluating it a second time
 > returns 1000, though.)
 >
 > Adding `(sit-for 0)' before the call to `window-width' make is return 1000
 > the first time, but it doesn't feel like a robust solution.
 >
 > Is this the expected behavior? If it is, is adding `(sit-for 0)' the
 > recommended way to get the correct window width after a frame resize?

Thanks for the report.  Just in due time to fix this for the release.
Moreover it allows me to remember the purpose of a change (something I
was unable to do in the discussion of bug#21380).  You can find the gory
details here:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21380

The corresponding commit is:

commit 8af8355c3f72500986f6f10b62714b228d6f35ee
Author: Martin Rudalics <rudalics@gmx.at>
Date:   Mon Aug 31 11:09:22 2015 +0200

     Don't call do_pending_window_change in signal handlers (Bug#21380)

     * src/gtkutil.c (xg_frame_resized):
     * src/xterm.c (x_set_window_size):
     * src/w32term.c (x_set_window_size): Don't call
     do_pending_window_change.

which should also explain why the NS port was not affected.

I'm not sure how to proceed.  Probably I'll have to revert that commit
but the consequences are pretty unclear at the moment (at least to me).

martin

bug#23320: 25.0.92; Window width not updated after frame resize (Win32 and GTK)

[Eli Zaretskii]

> Date: Wed, 20 Apr 2016 15:49:16 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
>  > I noticed a regression on 25.0.92 compared to 24.5 where the following code
>  > behaves differently on the w32 port. (On a recent GTK build it also
>  > misbehaves, but not under the NS port.)
>  >
>  >      (progn
>  >        (set-frame-size (selected-frame) 1000 400 t)
>  >        (window-width nil t))
>  >
>  > On 24.5, this evaluates to "1000". However, on 25.0.92 `window-width'
>  > returns the width prior to the frame resize. (Evaluating it a second time
>  > returns 1000, though.)
>  >
>  > Adding `(sit-for 0)' before the call to `window-width' make is return 1000
>  > the first time, but it doesn't feel like a robust solution.
>  >
>  > Is this the expected behavior? If it is, is adding `(sit-for 0)' the
>  > recommended way to get the correct window width after a frame resize?
> 
> Thanks for the report.  Just in due time to fix this for the release.
> Moreover it allows me to remember the purpose of a change (something I
> was unable to do in the discussion of bug#21380).  You can find the gory
> details here:
> 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21380
> 
> The corresponding commit is:
> 
> commit 8af8355c3f72500986f6f10b62714b228d6f35ee
> Author: Martin Rudalics <rudalics@gmx.at>
> Date:   Mon Aug 31 11:09:22 2015 +0200
> 
>      Don't call do_pending_window_change in signal handlers (Bug#21380)
> 
>      * src/gtkutil.c (xg_frame_resized):
>      * src/xterm.c (x_set_window_size):
>      * src/w32term.c (x_set_window_size): Don't call
>      do_pending_window_change.
> 
> which should also explain why the NS port was not affected.
> 
> I'm not sure how to proceed.  Probably I'll have to revert that commit
> but the consequences are pretty unclear at the moment (at least to me).

Isn't it true that expecting the frame dimensions change immediately
is unreliable?  If so, there's no bug here.

bug#23320: 25.0.92; Window width not updated after frame resize (Win32 and GTK)

[martin rudalics]

 > Isn't it true that expecting the frame dimensions change immediately
 > is unreliable?

According to Jan "Lisp code that expects resize changes to be handeled
synchronously and in order are fundamentally broken".

 > If so, there's no bug here.

But he also said that ours is "an attempt to be nice to Lisp".

The X port handles this via x_wait_for_event.  IIRC you proposed to do
the same for the w32 port.  Either I try (and it will take some days or
maybe weeks), or you do (and it will take some minutes or maybe hours)
or you tell me what I have to do and we might be able to finish this
task somewhere in between.  How do we proceed?

martin

bug#23320: 25.0.92; Window width not updated after frame resize (Win32 and GTK)

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 20 Apr 2016 15:49:16 +0200, martin rudalics <rudalics@gmx.at> said:

> You can find the gory details here:

> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21380

> The corresponding commit is:

> commit 8af8355c3f72500986f6f10b62714b228d6f35ee
> Author: Martin Rudalics <rudalics@gmx.at>
> Date:   Mon Aug 31 11:09:22 2015 +0200

>      Don't call do_pending_window_change in signal handlers (Bug#21380)

>      * src/gtkutil.c (xg_frame_resized):
>      * src/xterm.c (x_set_window_size):
>      * src/w32term.c (x_set_window_size): Don't call
>      do_pending_window_change.

xg_frame_resized is certainly called from the read_socket_hook
context, and it seems to be a bad idea to call
do_pending_window_change there.  But does that really apply to
x_set_window_size?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#23320: 25.0.92; Window width not updated after frame resize (Win32 and GTK)

[Eli Zaretskii]

> Date: Thu, 21 Apr 2016 11:15:05 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: andlind@gmail.com, 23320@debbugs.gnu.org
> 
>  > Isn't it true that expecting the frame dimensions change immediately
>  > is unreliable?
> 
> According to Jan "Lisp code that expects resize changes to be handeled
> synchronously and in order are fundamentally broken".
> 
>  > If so, there's no bug here.
> 
> But he also said that ours is "an attempt to be nice to Lisp".
> 
> The X port handles this via x_wait_for_event.  IIRC you proposed to do
> the same for the w32 port.  Either I try (and it will take some days or
> maybe weeks), or you do (and it will take some minutes or maybe hours)
> or you tell me what I have to do and we might be able to finish this
> task somewhere in between.  How do we proceed?

The only idea I had back then was to wait for 20 msec or such likes.
Trying that should be easy, and should not take days ;-)

Thanks.

bug#23320: 25.0.92; Window width not updated after frame resize (Win32 and GTK)

[martin rudalics]

 >>       Don't call do_pending_window_change in signal handlers (Bug#21380)
 >
 >>       * src/gtkutil.c (xg_frame_resized):
 >>       * src/xterm.c (x_set_window_size):
 >>       * src/w32term.c (x_set_window_size): Don't call
 >>       do_pending_window_change.
 >
 > xg_frame_resized is certainly called from the read_socket_hook
 > context, and it seems to be a bad idea to call
 > do_pending_window_change there.  But does that really apply to
 > x_set_window_size?

Thanks for the kind reminder.  If it weren't for you, I would have
continued to find culprits in all possible directions.

Then, Pip Zeta explicitly wrote

   I think the problem is the call to do_pending_window_change in
   xg_frame_resized in gtkutil.c:

and I apparently decided that it's time to throw out all babies with the
bathwater.

Thanks again, martin

bug#23320: 25.0.92; Window width not updated after frame resize (Win32 and GTK)

[martin rudalics]

 > The only idea I had back then was to wait for 20 msec or such likes.
 > Trying that should be easy, and should not take days ;-)

Yes.  But the real cause for this bug was plain stupidity.  Sorry for
bothering you.

Thanks, martin

bug#23320: 25.0.92; Window width not updated after frame resize (Win32 and GTK)

[martin rudalics]

 > I noticed a regression on 25.0.92 compared to 24.5 where the following code
 > behaves differently on the w32 port. (On a recent GTK build it also
 > misbehaves, but not under the NS port.)
 >
 >      (progn
 >        (set-frame-size (selected-frame) 1000 400 t)
 >        (window-width nil t))
 >
 > On 24.5, this evaluates to "1000". However, on 25.0.92 `window-width'
 > returns the width prior to the frame resize. (Evaluating it a second time
 > returns 1000, though.)
 >
 > Adding `(sit-for 0)' before the call to `window-width' make is return 1000
 > the first time, but it doesn't feel like a robust solution.
 >
 > Is this the expected behavior? If it is, is adding `(sit-for 0)' the
 > recommended way to get the correct window width after a frame resize?

Should be fixed now.  Please consider closing the bug after confirming.

And great many thanks for this report, martin

bug#23320: 25.0.92; Window width not updated after frame resize (Win32 and GTK)

[martin rudalics]

 > Should be fixed now.  Please consider closing the bug after confirming.

Bug closed now.

Thanks, martin