This is my first appearance in the xmonad community. Those tracking awesome may recognize this post as similar to one I posted earlier on that mailing list. Some backstory As a longtime C++ programmer I had assumed that awesome's imperative codebase (C++ and Lua) would present a gentler learning curve. I made some initial progress but ultimately found awesome still too immature and undocumented to give me confidence of achieving my various goals (of which possibly more in a subsequent posting). On switching to xmonad the greater maturity, generally good documentation, abundance of contributed modules and availablity of example configurations helped me greatly. The only thing I miss from awesome is its somewhat snappier performance. My guess would be that that has nothing to do with choice of implementation or scripting language, but rather with the fact that awesome is built on xcb while xmonad is built on classic xlib. My current challenge Years ago I loved Apollo workstations' DM (Display Manager). Ever since becoming an emacs user I have dreamed of recreating that environment. The emergence of robust tiling window managers and the example of Drew Adams' OneOnOne package (http://www.emacswiki.org/emacs/OneOnOneEmacs) leads me to believe that after a couple decades the dream may now be close to realization. For reference my environment is Ubuntu Jaunty, Gnome with a single top panel on a 1920x1200 screen. Under Gnome/Metacity I have emacs-snapshot (23.0.93.1) more or less working in the the single mini-buffer for all windows mode. (Here I use the term window to refer to what in the Emacs world would be called a frame.) The mini-buffer window is positioned at the bottom of the screen and is full-screen wide. Alternatively I can position the mini-buffer at the top of the screen just below the Gnome panel. Now I want to move this Emacs arrangement to xmonad. Because I have arranged for the mini-buffer window to have a distinct resource type I can recognize it in a manage hook. From the xmonad FAQ and some googling I believe that when that window appears I need to set its override-redirect attribute to true and define it as a strut. Though I am working my way through Hal Daumé's "Yet Another Haskell Tutorial" I fear it may be a while before I can code such a doStrut function. Thus my appeal to the readers of this list. My sense is that when the mini-buffer window appears it is properly sized and positioned. Thus there should be no need to compute the strut components, they should be directly liftable from the window. Thanks in advance for any help, /john