From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Description of problem:
When you try to maximize xemacs, it chews up the processor and freezes
up. It doesn't even get to the point of redrawing the scrollbars in
the right place.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run xemacs (this still works with "-q", so it's not init file specific)
2. Click on the maximization button
3. Watch as xemacs happily eats all of your CPU and ignores your
keystrokes. Your cursor will also start flashing.
I'm apparently not the only one to notice this one:
Unfortunately I haven't received any feedback from upstream about this.
Oh, I should add that it seems be be metacity specific afaict:
eg it doesn't seem to happen under KDE for example.
Havoc, do you have any comments/ideas about this?
XEmacs upstream are aware of the issue.
Still occurs with 21.4.15.
*** Bug 111896 has been marked as a duplicate of this bug. ***
Regular GNU Emacs used to rely on the WM implementing a short-circuit,
1. Emacs asked for size WxH
2. Metacity assigned it WxH
3. Emacs would ask for WxH again
4. If Metacity assigned WxH back as requested, the loop continued;
GNU Emacs requires the WM here to do nothing if WxH is already
the current size
Basically GNU Emacs was on crack and always sent another "please
resize me" request in response to a "you have been resized" event.
Maybe XEmacs has some similar weirdness.
The way the specs are written this almost certainly is technically
XEmacs's fault, since the WM is given full authority over sizes and
apps are required to accept anything. However there may be a simple
workaround in the WM.
I'd just add that clicking "unmaximize" (or hitting alt-f5) will
restore the window to wrong size (vertical size will be "unmaximized"
size, but horizontal size will be "maximized" (full screen widht)
size). Also, hitting "unmaximize" will get xemacs out of the infinite
I believe this was recently fixed in the 21.5 beta series.,
but didn't get round to backporting the fix...
Can we expect some fix in the near future?
From XEmacs 21.4.17 release notes, http://www.xemacs.org/Releases/21.4.17.html
* Fix: Make window maximization work under Metacity.
XEmacs 21.4.17 is already in Extras for FC4 and later. Jens can answer for
earlier FC versions (Jens, feel free to set the status of this bug as you wish.
As far as I'm concerned, this is CLOSED (RAWHIDE|CURRENTRELEASE) but then
again, I'm a KDE user so I haven't even experienced the issue... it would be
nice if someone could verify whether this is indeed fixed in 21.4.17 or not).
As a side note, the FE4/devel xemacs-21.4.17 and latest xemacs-sumo should be
buildable on earlier distro versions. I'm running such rebuilt ones on FC3,
they work fine for me.
No, it is not fixed yet in xemacs-21.4.17-3 afaict.
Looks like if Emacs doesn't get its requested size, it just keeps asking for it.
Ok, got a chance to test, and indeed this is not completely fixed. Damn.
I cannot get XEmacs 21.4.17 to freeze though. It (and X) does consume quite a
bit of CPU when XEmacs tries to maximize (apparently repeatedly trying to
resize, buffers tab flickers etc), but I can use it otherwise during that state.
The problem mentioned in comment 7 happens also in KDE (where the repeated
resize effect does not occur), but with slightly different results. Anyway,
unmaximizing does not work.
BTW, the patch from the message Havoc pointed out is applied in 21.4.17, so this
is something in addition to that. Will try to have a look next week(ish).
*** Bug 164046 has been marked as a duplicate of this bug. ***
Created attachment 121105 [details]
This patch submitted by a RHEL customer is supposed to fix the problem
for 21.4 at least.
Thanks, but that's the same patch which was already discussed earlier here
(see comments 12 and 13); it has been already applied in upstream 21.4.17 but
should help with earlier 21.4.x versions.
It appears to fix the lockups seen by some people, but still doesn't allow
XEmacs to unmaximize after maximizing :(
By the way, I had a chance to test the bleeding edge 21.5.x from CVS, and the
problem persists there.
The problem is present in "Red Hat Enterprise Linux WS release 4 (Nahant Update
2)" which has xemacs-21.4.15-10.EL.1. Upgrading to xemacs-21.4.17-0.FC2 does
not help even though that version includes a maximization fix for MetaCity.
The kde bug 93155 relating to this was closed as "Invalid" so the bug is
believed to be caused by xemacs (http://bugs.kde.org/show_bug.cgi?id=93155).
The bug is present under KDE and GNOME but xemacs maximize/restore works ok with
Open MOTIF and Blackbox window managers (all running RHEL4 update 2).
Still present in 21.4.19-3.fc5
Maximizing/minimizing appears to work for me on FC5, GNOME, all updates
installed, 21.4.19-4.fc5 (and 21.5.26-4 from devel rebuilt on FC5).
There's at least one glitch though: after maximizing the window, the text
content area is not immediately resized to cover all of the maximized window,
but it takes a few seconds.
Other experiences with latest FC5 updates installed?
Oh, yes, works for me too. It is funny how the text window takes some seconds
to update: perhaps that is why it was thought not to be working yet at all
until now? But this is a big improvement and after maximising the first time
subsequent times seem to be instant.
More good news, upstream has posted a patch that fixes rest of the maximization
problems for me in GNOME and KDE.
The patch is currently available for XEmacs 21.5.x series only though, and is
applied in the just-queued 21.5.26-5.fc6 for FE devel:
Hopefully a similar fix will be available for the 21.4.x series soon too.
This bug hasn't been updated in a long time and targets FE devel.
Could you please check that it still occurs with current FE devel and update
This bug has been fixed, and does not appear in the version of XEmacs that is on
the Fedora Extras repository for Fedora Core 6.
I'll confirm that I haven't seen this in a while. Currently using
xemacs-21.5.27-6.fc6 (latest production) and fully updated FC6 GNOME WM.
Thanks for the comments, however I'm pretty certain that 21.4.x series in FC5 is
still affected -> adjusting version accordingly.
FC5 is EOL, closing as CURRENTRELEASE.