Bug#589432: icewm: Emacs hangs on start
Evgeny M. Zubok
Version: 1.3.7~pre2-1
Severity: important
I've backported IceWM 1.3.7pre2 to Lenny and encountered the problem
with Emacs - it doesn't respond just after mapping. All other
applications start as usual. I use emacs22 from Lenny which is
compiled with Xaw3d by default. In testing/sid, emacs23-lucid is built
with Xaw3d, but I don't try it. To reproduce the issue just start
'emacs -Q' (i. e only pure emacs without any configuration files).
Before that I was using the IceWM 1.3.5-2 which was also backported to
Lenny. With this version all was fine.
-- System Information:
Debian Release: 5.0.5
APT prefers stable
APT policy: (990, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-486
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages icewm depends on:
ii icewm-common 1.3.7~pre2-1 wonderful Win95-OS/2-Motif-like wi
ii libc6 2.7-18lenny4 GNU C Library: Shared libraries
ii libesd0 0.2.36-3 Enlightened Sound Daemon - Shared
ii libfontconfig1 2.6.0-3 generic font configuration library
ii libgcc1 1:4.3.2-1.1 GCC support library
ii libglib2.0-0 2.16.6-3 The GLib library of C routines
ii libgtk2.0-0 2.12.12-1~lenny2 The GTK+ graphical user interface
ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library
ii libsm6 2:1.0.3-2 X11 Session Management library
ii libx11-6 2:1.1.5-2 X11 client-side library
ii libxext6 2:1.0.4-2 X11 miscellaneous extension librar
ii libxft2 2.1.12-3 FreeType-based font drawing librar
ii libxinerama1 2:1.0.3-2 X11 Xinerama extension library
ii libxrandr2 2:1.2.3-1 X11 RandR extension library
icewm recommends no packages.
Versions of packages icewm suggests:
pn icewm-gnome-support <none> (no description available)
ii ttf-bitstream-vera 1.10-7 The Bitstream Vera family of free
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Evgeny M. Zubok
The same story with emacs23-lucid from lenny-backports repository.
Evgeny M. Zubok
problem. I haven't changed the tag to 'patch' bacause I don't know
whether to blame emacs or IceWM (I believe the former). Emacs23 with GTK
frontend works fine with current IceWM. Both emacs22 (Xaw3d, Lenny) and
emacs23-lucid (Xaw3d, Squeeze) are not usable with IceWM newer than
1.3.6 and require the patch.
Evgeny M. Zubok
thanks
I've found where the problem arises. Once IceWM issues ConfigureNotify
event to Emacs, the ConfigureNotify handler in Emacs (src/xterm.c)
sets win_gravity in WM_NORMAL_NINTS for Emacs window. IceWM recieves
PropertyNotify event and then calls the following functions (in the
call order):
IceWM receives PropertyNotify:
handleProperty (case XA_WM_NORMAL_HINTS)
updateMwmHints
configureClient
setNormalGeometryInner
updateLayout
setWindowGeometry
performLayout
sendConfigure
sendConfigure() again sends a synthetic ConfigureNotify event to Emacs
and we fall into the infinite loop. The loop can be broken if the
Emacs window gets fullscreen, rolled of iconified (see updateMwmHints
and configureClient "if"'s). Before the icewm-1.3.6, setWindowGeometry
had never sent synthetic ConfigureNotify event.
The question is: why we need to send ConfigureNotify when the
WM_NORMAL_HINTS get changed? I've searched through ICCCM and EWMH for
the cases when the ConfigureNotify synthetic event must be sent to
application. Nothing states that changing of WM_NORMAL_HINTS requires
this event and also the window reconfiguration. The synthetic
ConfigureNotify is requred for window reconfiguration (see 4.1.5,
4.2.3, 4.2.4 in ICCCM). IMO, we shouldn't send ConfigureNotify event
when the WM_NORMAL_HINTS is updated by application.
performLayout() is called also from configure() (src/decorate.cc),
where the body of performLayout() was before icewm-1.3.6. The best
what I can do is to move sendConfigure() from performLayout() back to
the configure(), where it was in pre-1.3.6 times. sendConfigure() only
sends synthetic ConfigureNotify event.
Patch that solves the problem with Emacs is attached.