Turning emacs mini-buffer window into a strut
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
John Yates
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.
You might have luck using the XMonad.Layout.Gaps layout in contrib, and by having a managehook that ignores the emacs minibuffer window (using doIgnore). This wouldn't be dynamic (moving the emacs window would require you to reconfigure it), but could work as a kludge until you manage to do it properly.
John Yates
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.
I don't know whether this is the best approach, but it occurs to me that having the mini-buffer frame declare itself as a strut (by setting _NET_WM_STRUT_PARTIAL) might be a good way to do it? There's an xmonad extension to handle struts, and presumably other window managers could make use of it, too. (I don't know whether this could be done in elisp. Hmm, I guess it's not, but that feels like a logical thing for Emacs to be able to do, so maybe add a frame parameter to do that?)
Bruce, Thanks for the quick reply.
I don't know whether this is the best approach, but it occurs to me that having the mini-buffer frame declare itself as a strut (by setting _NET_WM_STRUT_PARTIAL) might be a good way to do it?
A fully-tiled mini-buffer is amazingly frustrating. It moves around and invariably has a disconcerting aspect ratio. Having an Emacs mini-buffer-only frame declared as some form of strut would seem appropriate. The xmonad FAQ suggests that being able to set override redirect is also important. And for good measure the _NET_WM_WINDOW_TYPE should probably be changed from _NET_WM_WINDOW_TYPE_NORMAL to _NET_WM_WINDOW_TYPE_DOCK.
There's an xmonad extension to handle struts, and presumably other window managers could make use of it, too.
Absolutely. Down the road I would love to have the freedom to experiment easily with various window managers without each time having to contend with a screwy mini-buffer.
(I don't know whether this could be done in elisp. Hmm, I guess it's not, but that feels like a logical thing for Emacs to be able to do, so maybe add a frame parameter to do that?)
Emacs already has a number of frame parameters that seem to exist only to be passed through as window attributes. Similarly window type and override redirect could be exposed as simple pass-throughs. By contrast a strut or strut_partial property probably would have to examine at least the top, left, height, and fullscreen frame parameters. History suggests that getting such changes into an Emacs release could take a while. Near term I will continue to pursue the xmonad manage hook approach of modifying the window's properties. Such a capability might prove useful in making other applications run comfortably under xmonad while remaining tiled. /john
I'm thinking that the most flexible way of doing this would be to write a layout modifier that declares different parts of the screen to be dedicated to certain types of clients, while the remainder of the screen uses any regular layout. Doing this using a modifier has the advantage that the client doesn't have to cooperate and one could have multiple reserved screen areas (e.g., bottom, very narrow for the minibuffer, left for emacs speedbar, etc.) If you want to do it using struts, I can only see three ways of doing it, and neither seems too appealing: 1. Set the strut statically, but what if you want to use the same workspace for other stuff later on. The strut is still there. 2. The suggestion by Bruce: make the minibuffer window set _NET_WM_STRUT_PARTIAL. 3. Same as (1) but create and tear down the strut as part of window management whenever the minibuffer window appears/disappears. I'm not sure how to do (3), and it may in fact be easy, but I suspect that it would end up being more kludgy than writing the above layout modifier, which shouldn't be hard at all. Cheers, Norbert On Sat, May 02, 2009 at 07:43:49PM -0400, John Yates wrote:
Bruce,
Thanks for the quick reply.
I don't know whether this is the best approach, but it occurs to me that having the mini-buffer frame declare itself as a strut (by setting _NET_WM_STRUT_PARTIAL) might be a good way to do it?
A fully-tiled mini-buffer is amazingly frustrating. It moves around and invariably has a disconcerting aspect ratio.
Having an Emacs mini-buffer-only frame declared as some form of strut would seem appropriate. The xmonad FAQ suggests that being able to set override redirect is also important. And for good measure the _NET_WM_WINDOW_TYPE should probably be changed from _NET_WM_WINDOW_TYPE_NORMAL to _NET_WM_WINDOW_TYPE_DOCK.
There's an xmonad extension to handle struts, and presumably other window managers could make use of it, too.
Absolutely. Down the road I would love to have the freedom to experiment easily with various window managers without each time having to contend with a screwy mini-buffer.
(I don't know whether this could be done in elisp. Hmm, I guess it's not, but that feels like a logical thing for Emacs to be able to do, so maybe add a frame parameter to do that?)
Emacs already has a number of frame parameters that seem to exist only to be passed through as window attributes. Similarly window type and override redirect could be exposed as simple pass-throughs. By contrast a strut or strut_partial property probably would have to examine at least the top, left, height, and fullscreen frame parameters.
History suggests that getting such changes into an Emacs release could take a while. Near term I will continue to pursue the xmonad manage hook approach of modifying the window's properties. Such a capability might prove useful in making other applications run comfortably under xmonad while remaining tiled.
/john _______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
-- "And it happened all the time that the compromise between two perfectly rational alternatives was something that made no sense at all." -- Neal Stephenson, Anathem
participants (4)
-
Bruce Stephens -
John Yates -
mail＠justinbogner.com -
Norbert Zeh