[xmonad] Turning emacs mini-buffer window into a strut

[Norbert Zeh]

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 at 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