Re: window groups

[martin rudalics <rudalics@gmx.at>]

 > Temporary windows (e.g., completion, help) would be less of a problem
 > if there was support for splitting a frame at the *top* of the window
 > tree.  Ditto for toolbars.

Could you explain what you mean here?  The toolbar is not part of a
frame's root window.

 > I admit I don't run the current almost
 > released emacs but, as far as I know, there is no clean way to split
 > a frame that way.    For example, split a frame vertically.   Split each
 > half horizontally.   Then invoke a complex command that will pop up
 > a completion helper.     Ideally the completion helper would split the
 > entire frame, adding a new temporary window just above the minibuffer.
 > Instead, one of your four windows is taken over.   In the case of a
 > persistent
 > pop-up (like a help window), it would be nice to take some care so that if
 > the window config doesn't change other than by that window being deleted,
 > the former windows return precisely to their former sizes and locations.
 > Similarly, frame-wide toolbars could be popped up as frame-level window
 > splits -- this would make the minibuffer less special.

Returning "precisely" to former sizes is non-trivial.

 > (It might even be
 > worth exploring the practicality of making complex command invocation
 > a *non*-recursive operation -- it might be significantly easier than adding
 > cooperative threads and even if threads come along it could still be a
 > beneficial thing to do.)

Do you mean to pop-up a new window for each command invocation?

 > Window-local variables would also be handy.   "Apps" can search
 > window bindings to find which window to take over for a particular
 > buffer being popped up.   And, as I earlier argued, window-local variables
 > could help make the point, mark, and selection cleaner -- so now I've
 > got two arguments in favor of the long-contemplated window-local vars.

I always wanted them.  However, as Stefan points out in another thread,
this seems to be difficult.