Re: window groups

[Chong Yidong <cyd@stupidchicken.com>]

martin rudalics <rudalics@gmx.at> writes:

> Conceptually, (2) should be sufficient to satisfy the requirements of
> most IDE layouts like those of ECB or Eclipse "perspectives".
>
> - IDEs would typically specify one window group ("edit-area" in ECB,
>   "editor" in Eclipse) for each frame.  Splitting any window of that
>   group would be done by setting the GROUP argument for `split-window'
>   to t.  Other applications would not interfere with the layout of that
>   group since, by default, their GROUP argument would not be t.
>
> - IDE windows around that group (Eclipse "views") would be created as
>   follows: For the first such window either (i) call `split-window' with
>   GROUP set to `root' to obtain a full-height|width view, or (ii) call
>   `split-window' with GROUP set to nil to obtain a window just as
>   high|wide as the window group.  Further windows would be created by
>   splitting an existing window with GROUP set to nil (or t for the more
>   complex layout-outlines of ECB ).
>
>   Approach (i) appears best for displaying views on the left or right of
>   the edit area (file or tag views like the speedbar).  Approach (ii)
>   might be given preference for displaying windows above or below the
>   edit area (compile, shell, or grep views).

It seems to me that, in practice, any Elisp application that needs to
control the window configuration will probably want to control over the
entire frame.  Otherwise, the resulting windows will likely be too
small.  WDYT?  If so, maybe all that needs to be done, infrastructure
wise, is a few functions for, e.g., creating window configurations from
scratch, rather than window groups.

I also think that the main problem here is the *user interface* to allow
the user to choose one of several window configurations, akin to the
"perspectives browser".  Have you thought about how that might be
implemented?