problem with maximize on xemacs

Thanks for your bug. Could you provide some more information - is the bug still reproducible and if so, what specific steps should be taken to reproduce it? What do you expect to happen and what actually happens? Is it on Gnome or KDE? Are you now using Dapper and does it still occur there?

Thanks.

to reproduce this bug:
- start xemacs
- click the maximize button (on top left of the window)

then xemacs take about 2 second to maximize properly

I can confirm this bug.

It occurs because of bad interaction between Metacity (the default Ubuntu window manager) and XEmacs.

When you press "maximise", Metacity tells XEmacs to resize its window to the correct size, in pixels. XEmacs does not resize to the size it is told to. It maximises to a multiple of the size of the fixed-width font.

Metacity is not impressed, and tells XEmacs again to resize to the correct size. XEmacs again does not resize to the size it is told to. And so this goes on indefinitely, as neither Metacity nor XEmacs is willing to back down.

The XEmacs developers initially blamed the window manager, but they later checked the ICCCM, and found they were in the wrong; the window manager has the absolute right to decide the window dimensions of a window. If it tells you to change to a particular size, you obey!

A patch was devised and accepted to CVS around 2004-12-15:
http://calypso.tux.org/pipermail/xemacs-beta/2004-December/004047.html
http://calypso.tux.org/pipermail/xemacs-beta/2004-December/004048.html

It was fixed "for real" on 2006-04-30: From the XEmacs src/ChangeLog:

2006-04-30 Stephen J. Turnbull <email address hidden>

 Move geometry management from EmacsFrameResize to x_set_frame_size.
 Should fix "metacity maximization" bug.
 Provide (deprecated, temporary) backward compatibility option.

 * EmacsFrame.c (EmacsFrameResize):
 * frame-x.c (x_set_frame_size):
 Move call of EmacsManagerChangeSize.
 Don't bogusly notify WM about size changes the WM asked for.

 * console-x.c (wedge-metacity): New builtin Boolean Lisp variable.
 * console-x-impl.h (wedge_metacity): Declare C variable.
 * console-x.c (vars_of_console_x): New function to initialize it.
 * symsinit.h (vars_of_console_x): declare it.
 * emacs.c (main_1): Call vars_of_console_x.

 * EmacsFrameP.h (struct EmacsFrame):
 * EmacsManager.c (EmacsManagerChangeSize):
 * EmacsShell-sub.c (SuperClassRootGeometryManager):
 * console-x-impl.h (wedge_metacity):
 Various comments, some improved documentation, mostly sad comments
 on the state of the art of Xt programming.

 * frame-x.c (defi): #undef it. (Random code cleanliness.)

This was eventually released in XEmacs 21.5.27, released 2006-05-16. This is a beta release.
http://www.xemacs.org/Releases/21.5.27.html

So the problem has been fixed upstream, at least in beta.

Currently, Feisty includes XEmacs 21.4.19, released 2006-01-28 and Gutsy includes XEmacs 21.4.20, released 2006-12-09. These are both stable releases rather than betas. Neither of these yet have the fix to make XEmacs work correctly with metacity.

I went through the CVS sources and extracted the diffs of Stephen's fix. These are attached.

I went through the above diffs. Most of the changes are only comments, for good maintenance of the source code. He also made the fix backwards compatible by adding an extra variable to lisp which turns off the new behaviour and reverts to the broken behaviour.

I don't think we need either of these things, because Ubuntu only supports with Metacity, so we don't need a switch to re-enable broken behaviour. Also, as we are only tracking the stable version, we don't need to add comments towards the maintenance of the software - that will appear upstream in time.

So, here is the patch to apply to the current Gutsy version of XEmacs which fixes the bug.

I built the xemacs packages with the and they now work

Before, maximizing led to an infinite loop.
Now, maximizing happens, xemacs takes a couple of seconds to react, but becomes usable soon rather than indefinitely trying to resize

This bug was fixed in the package xemacs21 - 21.4.21-1ubuntu3

---------------
xemacs21 (21.4.21-1ubuntu3) hardy; urgency=low

  'Don't touch old bugs, they could be easy to fix'
  * debian/patches/21_fix_maximation_bug.dpatch: (LP: #3982)
    - Fix maximation issue, where xemacs21 meant to stay in an infinite loop

 -- Stephan Hermann <email address hidden> Thu, 06 Mar 2008 20:14:53 +0100

The afforementioned fix does not fix the problem for me.

Using xemacs - 21.4.21-1ubuntu3 on a clean hardy amd64 installed. When I maximize xemacs, various elements in its display flicker (esp. the XEmacs logo and the scratch buffer tab on top). CPU usage goes to 100%, mostly consumned by xemacs, Xorg, and compiz.real. Xemacs becomes extremely sluggish.

This happens when Visual Effects in the Appearance preferences are set to Normal or Extra, but not when set to None.

Dropped status down to "In Progress" because the released fix apparently does not always work.

It seems that the bug I experience is still related to bad resizing interaction with the window manager.

If I trace X events to xemacs with xev, and then click on maximize so that xemacs goes into its "endless flickering" loop, then after the first few events, the following two events are repeated ad nauseam:

PropertyNotify event, serial 13, synthetic NO, window 0x3c0002c,
    atom 0x28 (WM_NORMAL_HINTS), time 92016876, state PropertyNewValue

ConfigureNotify event, serial 13, synthetic YES, window 0x3c0002c,
    event 0x3c0002c, window 0x3c0002c, (1,52), width 1277, height 943,
    border_width 1, above 0x380038b, override NO

Hmm...

you said that it's only happening with compiz but not with a "plain" wm?

Sounds more like a problem in compiz wm then...

The behaviour I reported (an infinite repetition of PropertyNotify/ConfigureNotify) events that I reported earlier seems consitent with Kyzer's comment earlier on in this thread, about the original cause of the flickering bug.

In the meantime I have discovered that the flickering I report happens with the binary from the xemacs21-gnome-mule package, and not with the xemacs21-gnome-nomule package. This all on amd64 on Hardy.

Wow.

Now it is 2010; I am running 10.04 ... and the problem is still there.
Oh great.

It's now 2012, and the problem is still present on ubuntu 12.04. Hooray.

And to be clear, this affects both composited and non-composited desktops.

+1: same problem since 5+ years here. Maximizing does not move the side scrollbars (they stay where they were before maximizing). Manually resizing the window to match the screen works fine.

10 years since original bug filed on Red Hat list. Still plaguing me to this day. Any plans on addressing it?

Filing a "me too" comment here is not a constructive contribution. Ubuntu / Canonical mainly tracks upstream for xemacs21 (and barely even that).

If you can reproduce with the current xemacs21 development sources and provide upstream with useful diagnostics, please do. If you can contribute a patch upstream, even better.

If you can find a valid upstream bug (I don't see anything linked from this bug; also, searching for "maximize" at http://tracker.xemacs.org/XEmacs/its/ does not return any hits), please link it here. If there isn't one, and you are qualified to file a bug report upstream, please do, then link it here.

If you are willing to switch to GNU Emacs, which by and large offers the same functionality, that seems to have an active and responsive upstream, and a large user base within the Ubuntu community, as well as outside of Ubuntu.

Thank you for your cooperation, your patience, and your understanding.

Just for those looking for a workaround (Ubuntu 12.04): If one enters with "Ubuntu 2D" (instead just "Ubuntu" - that is "3D") XEmacs works without any troubles.