Re: window groups

[martin rudalics]

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