headers
John Yates | 2 May 2009 19:25

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
(Continue reading)

Permalink | Reply |
headers
Bruce Stephens | 2 May 2009 20:14
Picon
Picon

Re: Turning emacs mini-buffer window into a strut

John Yates <john@...> writes:

[...]

> 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?)
Permalink | Reply |
headers
John Yates | 3 May 2009 01:43

Re: Turning emacs mini-buffer window into a strut

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
(Continue reading)

Permalink | Reply |
headers
Norbert Zeh | 3 May 2009 16:03
Picon
Picon

Re: Turning emacs mini-buffer window into a strut

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.
>
(Continue reading)

Permalink | Reply |
headers
mail | 2 May 2009 20:14
Gravatar

Re: Turning emacs mini-buffer window into a strut

John Yates <john@...> writes:
> 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.
Permalink | Reply |

Gmane