bug#2401: 23.0.90; set-frame-width does not take effect immediately?

bug#2401: 23.0.90; set-frame-width does not take effect immediately?

[Alex Khesin]

Consider the following function

(defun test-split-window ()
  (interactive)
  (delete-other-windows)
  (set-frame-width (selected-frame) 80)
  (set-frame-width (selected-frame) 163)
  (split-window-horizontally -80))

Up to about a month ago, CVS emacs used to end up with a frame containing two 80-characters-wide windows after executing test-split-window.  I updated to the latest CVS earlier today, and I now get one of two behaviors: either the frame is made 80 wide but split in two, or the frame becomes 163 wide, but not split at all, with "Window width 0 (after splitting)" error message.  Adding short sleeps after set-frame-width fixes it:

(defun test-split-window ()
  (interactive)
  (delete-other-windows)
  (set-frame-width (selected-frame) 80)
  (sleep-for 0 500)
  (set-frame-width (selected-frame) 163)
  (sleep-for 0 500)
  (split-window-horizontally -80))

Executing the set-frame-window and split-window-horizontally by hand, one after another, also has the desirable effect.

It looks like set-frame-width does not take effect immediately anymore.


In GNU Emacs 23.0.90.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.12.9)
 of 2009-02-19 on alexk-warp.nyc.corp.google.com
Windowing system distributor `The X.Org Foundation', version 11.0.60900000
configured using `configure  '--with-x''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: C
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: C
  value of $LC_NUMERIC: C
  value of $LC_TIME: C
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Help

Minor modes in effect:
  googlemenu-mode: t
  which-function-mode: t
  desktop-save-mode: t
  recentf-mode: t
  cua-mode: t
  show-paren-mode: t
  savehist-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  view-mode: t

Recent input:
<up> <up> <up> <S-down> <S-down> <S-down> <S-down> 
<S-down> C-c <timeout> C-x b <return> <S-up> <S-up> 
<S-up> <S-up> <S-up> <S-up> <S-down> C-√ C-v <S-up> 
<S-up> <S-up> <S-up> <S-up> M-x e v a k <backspace> 
l - r e g <tab> <return> M-x a k - d o <tab> <return> 
M-x a k - s i n <tab> <return> M-x <up> <up> <return> 
<help-echo> <down-mouse-5> <mouse-5> <double-down-mouse-5> 
<double-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<down-mouse-4> <mouse-4> <double-down-mouse-4> <double-mouse-4> 
<up> <up> <down> <S-down> <S-down> <S-down> <S-down> 
<S-down> <S-down> C-c <timeout> M-x <help-echo> r e 
p o r t - e m a <tab> <return> a <return> <help-echo> 
<help-echo> <help-echo> <down-mouse-5> <mouse-5> <double-down-mouse-5> 
<double-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <down-mouse-4> <mouse-4> <double-down-mouse-4> 
<double-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <down-mouse-1> 
<mouse-1> M-x m a k e - f r <tab> <return> <switch-frame> 
C-x m n C-x m y a l e k <backspace> x k <backspace> 
@ k h e s i n . c o m <down> e s t <backspace> <backspace> 
<backspace> t e s t <down> <down> t e s t i n g <help-echo> 
C-c C-s C-x k <return> M-x a k - s i n <tab> <return> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> M-x 
a k - d o <tab> <return> M-x a k - d o <tab> <return> 
M-x a k - d <tab> <return> M-x a k - s i n <tab> <return> 
M-x a k - d o <tab> <return> M-x <up> <return> M-x 
a k s i n <tab> <backspace> <backspace> <backspace> 
<up> <up> <return> M-x <up> <up> <return> <switch-frame> 
M-x C-r b u g <return> <return>

Recent messages:
byte-code: Beginning of buffer
byte-code: End of buffer [5 times]
byte-code: Beginning of buffer [4 times]
Auto-saving...
Auto-saving *mail*: Opening output file: no such file or directory, /tmp/alexk/emacs_autosaves/home/alexk/#%*mail*#
Unsent message being composed; erase it? (y or n) 
sendmail-user-agent-compose: Message aborted
Unsent message being composed; erase it? (y or n) 
Sending...done
split-window-horizontally: Window width 0 too small (after splitting) [3 times]

bug#2401: 23.0.90; set-frame-width does not take effect immediately?

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 19 Feb 2009 23:05:53 -0500 (EST), Alex Khesin <alexk@google.com> said:

> Consider the following function
> (defun test-split-window ()
>   (interactive)
>   (delete-other-windows)
>   (set-frame-width (selected-frame) 80)
>   (set-frame-width (selected-frame) 163)
>   (split-window-horizontally -80))

> Up to about a month ago, CVS emacs used to end up with a frame
> containing two 80-characters-wide windows after executing
> test-split-window.  I updated to the latest CVS earlier today, and I
> now get one of two behaviors: either the frame is made 80 wide but
> split in two, or the frame becomes 163 wide, but not split at all,
> with "Window width 0 (after splitting)" error message.  Adding short
> sleeps after set-frame-width fixes it:

> (defun test-split-window ()
>   (interactive)
>   (delete-other-windows)
>   (set-frame-width (selected-frame) 80)
>   (sleep-for 0 500)
>   (set-frame-width (selected-frame) 163)
>   (sleep-for 0 500)
>   (split-window-horizontally -80))

> Executing the set-frame-window and split-window-horizontally by
> hand, one after another, also has the desirable effect.

> It looks like set-frame-width does not take effect immediately anymore.

This seems to be related to Bug#2980(*1) and both can only be
observable with GTK+ frames for me.  Below is my experimental change
for Bug#2980, and it is included in an (also experimental) GTK+ print
dialog support (*2).  Because the printing support measures page
boundary with pos-visible-in-window-p in an invisible frame, it needs
to know its size before receiving ConfigureNotify and calling
xg_frame_resized.

As far as I tested, this patch also works for this bug.

*1: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2980
*2: http://lists.gnu.org/archive/html/emacs-devel/2009-04/msg00390.html

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

RCS file: /cvsroot/emacs/emacs/src/gtkutil.c,v
retrieving revision 1.150
diff -c -p -r1.150 gtkutil.c
*** src/gtkutil.c	19 Apr 2009 10:53:19 -0000	1.150
--- src/gtkutil.c	3 May 2009 06:40:58 -0000
*************** xg_frame_set_char_size (f, cols, rows)
*** 736,741 ****
--- 736,767 ----
    x_wm_size_hint_off (f);
    gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
                       pixelwidth, pixelheight);
+ 
+ #if 1  /* XXX: experimental change for Bug#2980 */
+   /* Now, strictly speaking, we can't be sure that this is accurate,
+      but the window manager will get around to dealing with the size
+      change request eventually, and we'll hear how it went when the
+      ConfigureNotify event gets here.
+ 
+      We could just not bother storing any of this information here,
+      and let the ConfigureNotify event set everything up, but that
+      might be kind of confusing to the Lisp code, since size changes
+      wouldn't be reported in the frame parameters until some random
+      point in the future when the ConfigureNotify event arrives.
+ 
+      We pass 1 for DELAY since we can't run Lisp code inside of
+      a BLOCK_INPUT.  */
+   change_frame_size (f, rows, cols, 0, 1, 0);
+   FRAME_PIXEL_WIDTH (f) = pixelwidth;
+   FRAME_PIXEL_HEIGHT (f) = pixelheight;
+ 
+   /* We've set {FRAME,PIXEL}_{WIDTH,HEIGHT} to the values we hope to
+      receive in the ConfigureNotify event; if we get what we asked
+      for, then the event won't cause the screen to become garbaged, so
+      we have to make sure to do it here.  */
+   SET_FRAME_GARBAGED (f);
+ #endif
+ 
    flush_and_sync (f);
    x_wm_set_size_hint (f, 0, 0);
  }

bug#2401: 23.0.90; set-frame-width does not take effect immediately?

[Alex Khesin]

On Sun, May 3, 2009 at 3:07 AM, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
> As far as I tested, this patch also works for this bug.

Thank you, I just tried the patch and it does indeed work.

bug#2401: 23.0.90; set-frame-width does not take effect immediately?

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 6 May 2009 17:57:53 -0400, Alex Khesin <alexk@google.com> said:

> On Sun, May 3, 2009 at 3:07 AM, YAMAMOTO Mitsuharu
> <mituharu@math.s.chiba-u.ac.jp> wrote:
>> As far as I tested, this patch also works for this bug.

> Thank you, I just tried the patch and it does indeed work.

Jan, could you take a look at the patch in
http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2401 ?
The code and comment are just a copy from x_set_window_size_1.

Maintainers, I think this change needs your approval to be committed
at this stage, because Emacs 22 has the same problem and this is not a
fix for a regression.

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

bug#2401: 23.0.90; set-frame-width does not take effect immediately?

[Chong Yidong]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> Jan, could you take a look at the patch in
> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2401 ?
> The code and comment are just a copy from x_set_window_size_1.
>
> Maintainers, I think this change needs your approval to be committed
> at this stage, because Emacs 22 has the same problem and this is not a
> fix for a regression.

If Emacs 22 has the same problem, let's wait till after the release to
commit this.  The window manager handling code is delicate, and I don't
want to make this kind of change now.

bug#2401: 23.0.90; set-frame-width does not take effect immediately?

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 07 May 2009 23:19:53 -0400, Chong Yidong <cyd@stupidchicken.com> said:

> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>> Jan, could you take a look at the patch in
>> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2401 ?
>> The code and comment are just a copy from x_set_window_size_1.
>> 
>> Maintainers, I think this change needs your approval to be
>> committed at this stage, because Emacs 22 has the same problem and
>> this is not a fix for a regression.

> If Emacs 22 has the same problem, let's wait till after the release
> to commit this.  The window manager handling code is delicate, and I
> don't want to make this kind of change now.

I forgot to mention in the last mail that this is a GTK+-only problem.
If you compare the default builds, i.e., Xaw for Emacs 22, and GTK+
for Emacs 23, then one could argue this is a regression.

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

bug#2401: 23.0.90; set-frame-width does not take effect immediately?

[Chong Yidong]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> I forgot to mention in the last mail that this is a GTK+-only problem.
> If you compare the default builds, i.e., Xaw for Emacs 22, and GTK+
> for Emacs 23, then one could argue this is a regression.

No, we should compare the Emacs 23 GTK build with the Emacs 22 GTK
build.

Thanks for solving this, BTW.  This problem has been puzzling me for a
while.

bug#2401: 23.0.90; set-frame-width does not take effect immediately?

[Stefan Monnier]

>>> As far as I tested, this patch also works for this bug.
>> Thank you, I just tried the patch and it does indeed work.
> Jan, could you take a look at the patch in
> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2401 ?
> The code and comment are just a copy from x_set_window_size_1.
> Maintainers, I think this change needs your approval to be committed
> at this stage, because Emacs 22 has the same problem and this is not a
> fix for a regression.

I'd be in favor of installing this change, because it is is new in the
default config of Emacs-23 (yes, it was already present in Emacs-22's
Gtk code, but the fact that it only showed up in Emacs-23 indicates
that the Gtk version of Emacs22 is not used as often).


        Stefan

bug#2401: 23.0.90; set-frame-width does not take effect immediately?

[Jan Djärv]

YAMAMOTO Mitsuharu skrev:
>>>>>> On Wed, 6 May 2009 17:57:53 -0400, Alex Khesin <alexk@google.com> said:
> 
>> On Sun, May 3, 2009 at 3:07 AM, YAMAMOTO Mitsuharu
>> <mituharu@math.s.chiba-u.ac.jp> wrote:
>>> As far as I tested, this patch also works for this bug.
> 
>> Thank you, I just tried the patch and it does indeed work.
> 
> Jan, could you take a look at the patch in
> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2401 ?
> The code and comment are just a copy from x_set_window_size_1.

It seems to fix some other resize issues as well (notably removing/adding 
tool/menu bar repeatedly).  Good catch!

> 
> Maintainers, I think this change needs your approval to be committed
> at this stage, because Emacs 22 has the same problem and this is not a
> fix for a regression.

I'd vote for this patch to be comitted.  Granted, it is not a regression from 
Emacs 22, but it is simple and unlikely to break anything.  Furthermore, it 
only affects resizing of frames on the Gtk+ build.

	Jan D.

bug#2401: 23.0.90; set-frame-width does not take effect immediately?

[Chong Yidong]

Jan Djärv <jan.h.d@swipnet.se> writes:

> I'd vote for this patch to be comitted.  Granted, it is not a
> regression from Emacs 22, but it is simple and unlikely to break
> anything.  Furthermore, it only affects resizing of frames on the Gtk+
> build.

If you think it's safe, then I'll take your word for it.  Please go
ahead and commit.

bug#2401: 23.0.90; set-frame-width does not take effect immediately?

[Jan Djärv]

Chong Yidong skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> I'd vote for this patch to be comitted.  Granted, it is not a
>> regression from Emacs 22, but it is simple and unlikely to break
>> anything.  Furthermore, it only affects resizing of frames on the Gtk+
>> build.
> 
> If you think it's safe, then I'll take your word for it.  Please go
> ahead and commit.

Done.

	Jan D.

bug#2401: marked as done (23.0.90; set-frame-width does not take effect immediately?)

[Emacs bug Tracking System]

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


Your message dated Mon, 11 May 2009 08:45:14 +0200
with message-id <4A07C97A.5010206@swipnet.se>
and subject line Re: bug#2401: 23.0.90; set-frame-width does not take effect 	immediately?
has caused the Emacs bug report #2401,
regarding 23.0.90; set-frame-width does not take effect immediately?
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
2401: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2401
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 8139 bytes --]

From: Alex Khesin <alexk@google.com>
To: emacs-pretest-bug@gnu.org
Subject: 23.0.90; set-frame-width does not take effect immediately?
Date: Thu, 19 Feb 2009 23:05:53 -0500 (EST)
Message-ID: <20090220040553.77C342544F0@localhost>

Consider the following function

(defun test-split-window ()
  (interactive)
  (delete-other-windows)
  (set-frame-width (selected-frame) 80)
  (set-frame-width (selected-frame) 163)
  (split-window-horizontally -80))

Up to about a month ago, CVS emacs used to end up with a frame containing two 80-characters-wide windows after executing test-split-window.  I updated to the latest CVS earlier today, and I now get one of two behaviors: either the frame is made 80 wide but split in two, or the frame becomes 163 wide, but not split at all, with "Window width 0 (after splitting)" error message.  Adding short sleeps after set-frame-width fixes it:

(defun test-split-window ()
  (interactive)
  (delete-other-windows)
  (set-frame-width (selected-frame) 80)
  (sleep-for 0 500)
  (set-frame-width (selected-frame) 163)
  (sleep-for 0 500)
  (split-window-horizontally -80))

Executing the set-frame-window and split-window-horizontally by hand, one after another, also has the desirable effect.

It looks like set-frame-width does not take effect immediately anymore.


In GNU Emacs 23.0.90.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.12.9)
 of 2009-02-19 on alexk-warp.nyc.corp.google.com
Windowing system distributor `The X.Org Foundation', version 11.0.60900000
configured using `configure  '--with-x''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: C
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: C
  value of $LC_NUMERIC: C
  value of $LC_TIME: C
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Help

Minor modes in effect:
  googlemenu-mode: t
  which-function-mode: t
  desktop-save-mode: t
  recentf-mode: t
  cua-mode: t
  show-paren-mode: t
  savehist-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  view-mode: t

Recent input:
<up> <up> <up> <S-down> <S-down> <S-down> <S-down> 
<S-down> C-c <timeout> C-x b <return> <S-up> <S-up> 
<S-up> <S-up> <S-up> <S-up> <S-down> C-√ C-v <S-up> 
<S-up> <S-up> <S-up> <S-up> M-x e v a k <backspace> 
l - r e g <tab> <return> M-x a k - d o <tab> <return> 
M-x a k - s i n <tab> <return> M-x <up> <up> <return> 
<help-echo> <down-mouse-5> <mouse-5> <double-down-mouse-5> 
<double-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<down-mouse-4> <mouse-4> <double-down-mouse-4> <double-mouse-4> 
<up> <up> <down> <S-down> <S-down> <S-down> <S-down> 
<S-down> <S-down> C-c <timeout> M-x <help-echo> r e 
p o r t - e m a <tab> <return> a <return> <help-echo> 
<help-echo> <help-echo> <down-mouse-5> <mouse-5> <double-down-mouse-5> 
<double-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <down-mouse-4> <mouse-4> <double-down-mouse-4> 
<double-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <down-mouse-1> 
<mouse-1> M-x m a k e - f r <tab> <return> <switch-frame> 
C-x m n C-x m y a l e k <backspace> x k <backspace> 
@ k h e s i n . c o m <down> e s t <backspace> <backspace> 
<backspace> t e s t <down> <down> t e s t i n g <help-echo> 
C-c C-s C-x k <return> M-x a k - s i n <tab> <return> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> M-x 
a k - d o <tab> <return> M-x a k - d o <tab> <return> 
M-x a k - d <tab> <return> M-x a k - s i n <tab> <return> 
M-x a k - d o <tab> <return> M-x <up> <return> M-x 
a k s i n <tab> <backspace> <backspace> <backspace> 
<up> <up> <return> M-x <up> <up> <return> <switch-frame> 
M-x C-r b u g <return> <return>

Recent messages:
byte-code: Beginning of buffer
byte-code: End of buffer [5 times]
byte-code: Beginning of buffer [4 times]
Auto-saving...
Auto-saving *mail*: Opening output file: no such file or directory, /tmp/alexk/emacs_autosaves/home/alexk/#%*mail*#
Unsent message being composed; erase it? (y or n) 
sendmail-user-agent-compose: Message aborted
Unsent message being composed; erase it? (y or n) 
Sending...done
split-window-horizontally: Window width 0 too small (after splitting) [3 times]



[-- Attachment #3: Type: message/rfc822, Size: 2752 bytes --]

From: "Jan Djärv" <jan.h.d@swipnet.se>
To: Chong Yidong <cyd@stupidchicken.com>
Cc: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>, Stefan Monnier <monnier@iro.umontreal.ca>, Alex Khesin <alexk@google.com>, 2401@emacsbugs.donarmstrong.com, 2401-done@emacsbugs.donarmstrong.com
Subject: Re: bug#2401: 23.0.90; set-frame-width does not take effect 	immediately?
Date: Mon, 11 May 2009 08:45:14 +0200
Message-ID: <4A07C97A.5010206@swipnet.se>

Chong Yidong skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> I'd vote for this patch to be comitted.  Granted, it is not a
>> regression from Emacs 22, but it is simple and unlikely to break
>> anything.  Furthermore, it only affects resizing of frames on the Gtk+
>> build.
> 
> If you think it's safe, then I'll take your word for it.  Please go
> ahead and commit.

Done.

	Jan D.