GNOME Bugzilla – Bug 129916
breaks xemacs maximisation
Last modified: 2004-12-22 21:47:04 UTC
This bug was originally reported in the Debian BTS: http://bugs.debian.org/216775 "Hello. Latest metacity upgrade breaks xemacs-mule: after launching xemacs, if maximising completely (not just horizontal or vertical) causes xemacs to enter some kind of loop with the display flickering. Other programs seem not affected."
this has got to be a bug in xemacs. When metacity maximizes a window, it does two things: first, it does the move/resize, which results in a ConfigureNotify being sent to the window, either by metacity or by the X server. Second, it update the _NET_WM_STATE window property to include the _NET_WM_STATE_MAXIMIZED_VERT and _NET_WM_STATE_MAXIMIZED_HORZ. This will result in a PropertyNotify event being sent to the client if it's watching for such events. If xemacs is getting into a loop, it must be responding to the ConfigureNotify or the PropertyNotify in some incorrect manner. Not really sure what was changed in metacity 2.6.2 to bring out this behavior in xemacs, but if it's not metacity that's looping, I'd be surprised if this is a bug in metacity. I'll go ahead and test out this on xemacs to try to see what's going on before I mark NOTGNOME though.
OK I reproduced this problem; The moral of the story is that metacity maximizes the window and then it's just sitting there while xemacs freaks out doing god only knows what; it's not in some sort of window property ping pong with metacity or anything like that, so I'd have to so that is an xemacs bug. You can verify this by running metacity in verbose mode: METACITY_USE_LOGFILE METACITY_VERBOSE metacity --replace tail -f /tmp/metacity-*