bug#1289: 23.0.60; ridiculously large frame after maximizing and resizing back

bug#1289: 23.0.60; ridiculously large frame after maximizing and resizing back

[Sven Joachim]

Starting Emacs with `emacs --geometry=85x46+35+35 &' gives huge values
for (frame-height) and (frame-width) after maximizing the frame and
resizing it back:

before maximizing: (frame-height) => 46, (frame-width) => 85
after maximizing: (frame-height) => 65, (frame-width) => 124
after unmaximizing: (frame-height) => 716, (frame-width) => 889

My window manager is IceWM 1.2.35.

In GNU Emacs 23.0.60.12 (x86_64-unknown-linux-gnu, GTK+ Version 2.12.11)
 of 2008-11-01 on turtle
(Note that my userland is 32-bit, only the kernel is 64-bit.)

Windowing system distributor `The X.Org Foundation', version 11.0.10402000
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: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: de_DE.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Group

Minor modes in effect:
  gnus-undo-mode: t
  display-time-mode: t
  auto-image-file-mode: t
  show-paren-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
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
( f r a m e - h e i g h t ) <return> <backspace> C-j 
<return> ( f r a m e - w i d t h ) <return> <backspace> 
C-j <return> <up> <up> <up> <up> <up> <up> C-k C-k 
C-y <down> <down> <down> <down> <down> <down> <down> 
C-y <backspace> C-j <return> <up> <up> <up> <up> <up> 
<up> C-k C-k C-y <down> <down> <down> <down> <down> 
C-y <backspace> C-j <C-end> <return> C-y <up> <up> 
<up> <up> <up> <up> <up> C-k C-k C-y <down> <down> 
<down> <down> <down> C-y <up> <end> C-j <down> C-e 
C-j M-x e m <tab> a <tab> v e r s i o <tab> <return> 
M-x s e r v e r - s t <tab> <return> M-x g n u s <return> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> SPC <down> SPC <down> SPC q SPC <down> SPC q 
SPC q SPC q SPC q g <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <down> <down> <down> 
<down> <down> SPC > <down> SPC > <down> SPC > q M-x 
r e p o r t - e m <tab> <return>

Recent messages:
Opening nnfolder server on archive...done
Opening nntp server on news.gnus.org...done
Opening nntp server on news.motzarella.org...done
Checking new news...done
Retrieving newsgroup: gmane.linux.debian.devel.bugs.rc...
Opening nntp server on news.gmane.org...done
Fetching headers for gmane.linux.debian.devel.bugs.rc...done
Scoring...done
Generating summary...done
No more unread newsgroups

bug#1289: 23.0.60; ridiculously large frame after maximizing and resizing back

[Stefan Monnier]

> Starting Emacs with `emacs --geometry=85x46+35+35 &' gives huge values
> for (frame-height) and (frame-width) after maximizing the frame and
> resizing it back:

> before maximizing: (frame-height) => 46, (frame-width) => 85
> after maximizing: (frame-height) => 65, (frame-width) => 124
> after unmaximizing: (frame-height) => 716, (frame-width) => 889

> My window manager is IceWM 1.2.35.

Sounds like the remembered size is the window's pixel size but it is
then set (upon unmaximize) as a line&col size.
It might be a bug in IceWM, or at least a bad interaction.  If you can
reproduce it with some other program (e.g. xterm), then it's clearly an
IceWM bug.


        Stefan

bug#1289: 23.0.60; ridiculously large frame after maximizing and resizing back

[Sven Joachim]

On 2008-11-02 03:22 +0100, Stefan Monnier wrote:

>> Starting Emacs with `emacs --geometry=85x46+35+35 &' gives huge values
>> for (frame-height) and (frame-width) after maximizing the frame and
>> resizing it back:
>
>> before maximizing: (frame-height) => 46, (frame-width) => 85
>> after maximizing: (frame-height) => 65, (frame-width) => 124
>> after unmaximizing: (frame-height) => 716, (frame-width) => 889
>
>> My window manager is IceWM 1.2.35.
>
> Sounds like the remembered size is the window's pixel size but it is
> then set (upon unmaximize) as a line&col size.
> It might be a bug in IceWM, or at least a bad interaction.  If you can
> reproduce it with some other program (e.g. xterm), then it's clearly an
> IceWM bug.

So far I have not been able to reproduce it with any other program,
including Emacs 22.3.  Also, if I do something with the Emacs frame
(change its size or drag it around) before maximizing and unmaximizing,
the problem does not show up.

Sven

bug#1289: 23.0.60; ridiculously large frame after maximizing and resizing back

[Chong Yidong]

Could you try to roll back your revision to see when this problem first
appeared?  My guess is

  2008-10-06  Chong Yidong  <cyd@stupidchicken.com>

    * gtkutil.c (x_wm_set_size_hint): Return immediately if
    called during initialization.

so I suggesting checking that first.

bug#1289: 23.0.60; ridiculously large frame after maximizing and resizing back

[Sven Joachim]

On 2008-11-03 03:35 +0100, Chong Yidong wrote:

> Could you try to roll back your revision to see when this problem first
> appeared?  My guess is
>
>   2008-10-06  Chong Yidong  <cyd@stupidchicken.com>
>
>     * gtkutil.c (x_wm_set_size_hint): Return immediately if
>     called during initialization.
>
> so I suggesting checking that first.

Indeed, the problem goes away after reverting gtkutil.c to revision
1.138.

Sven

bug#1289: 23.0.60; ridiculously large frame after maximizing and resizing back

[Chong Yidong]

Sven Joachim <svenjoac@gmx.de> writes:

>>   2008-10-06  Chong Yidong  <cyd@stupidchicken.com>
>>
>>     * gtkutil.c (x_wm_set_size_hint): Return immediately if
>>     called during initialization.
>>
>> so I suggesting checking that first.
>
> Indeed, the problem goes away after reverting gtkutil.c to revision
> 1.138.

Does the following patch fix it?

*** trunk/src/xfns.c.~1.727.~	2008-10-28 11:24:26.000000000 -0400
--- trunk/src/xfns.c	2008-11-03 10:33:55.000000000 -0500
***************
*** 3099,3104 ****
--- 3099,3118 ----
    x_default_parameter (f, parms, Qfont, font, "font", "Font", RES_TYPE_STRING);
  }
  
+ DEFUN ("x-wm-set-size-hint", Fx_wm_set_size_hint, Sx_wm_set_size_hint,
+        0, 1, 0,
+        doc: /* Send the size hints for frame FRAME to the window manager.  */)
+      (frame)
+      Lisp_Object frame;
+ {
+   struct frame *f;
+   if (NILP (frame))
+     frame = selected_frame;
+   f = XFRAME (frame);
+   BLOCK_INPUT;
+   x_wm_set_size_hint (f, 0, 0);
+   UNBLOCK_INPUT;
+ }
  
  DEFUN ("x-create-frame", Fx_create_frame, Sx_create_frame,
         1, 1, 0,
***************
*** 5944,5949 ****
--- 5958,5964 ----
    defsubr (&Sx_display_visual_class);
    defsubr (&Sx_display_backing_store);
    defsubr (&Sx_display_save_under);
+   defsubr (&Sx_wm_set_size_hint);
    defsubr (&Sx_create_frame);
    defsubr (&Sx_open_connection);
    defsubr (&Sx_close_connection);
*** trunk/lisp/term/x-win.el.~1.235.~	2008-08-30 19:54:06.000000000 -0400
--- trunk/lisp/term/x-win.el	2008-11-03 10:33:09.000000000 -0500
***************
*** 1540,1545 ****
--- 1540,1548 ----
    ;; Don't let Emacs suspend under X.
    (add-hook 'suspend-hook 'x-win-suspend-error)
  
+   ;; Set wm hints after initialization
+   (add-hook 'after-init-hook 'x-wm-set-size-hint)
+ 
    ;; Turn off window-splitting optimization; X is usually fast enough
    ;; that this is only annoying.
    (setq split-window-keep-point t)

bug#1289: 23.0.60; ridiculously large frame after maximizing and resizing back

[Sven Joachim]

On 2008-11-03 16:41 +0100, Chong Yidong wrote:

> Does the following patch fix it?

Yes it does. :-)

Thanks,
       Sven

bug#1289: 23.0.60; ridiculously large frame after maximizing and resizing back

[Chong Yidong]

Sven Joachim <svenjoac@gmx.de> writes:

> On 2008-11-03 16:41 +0100, Chong Yidong wrote:
>
>> Does the following patch fix it?
>
> Yes it does. :-)

Thanks for checking.  I've checked in the fix.