Re: window groups

[Thomas Lord <lord@emf.net>]

Miles Bader wrote:
>  when
> I've thought about this sort of thing before, my thoughts tended towards
> making the existing Emacs window tree more visible to lisp code, and
> adding some mechanism for specifying where in the tree various
> operations would be directed by default.]
>   

The very tree-centric primitives for window management and the
limited nature of window configurations has been a long-standing
source of frustration, I agree.    Lots of more flexible approaches to
geometry management have come along in the last 20 years.   Emacs
adds to the geometry management problem the constant (but rewarding)
challenge of not breaking terminal support, yet this area still seems
just stuck in the distant past (not because of terminal support -- just
because it could be much nicer).

However, for some simple ideas not requiring radical revision:

The first one should be very easy.   The second one is a little harder:

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

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.

-t