Re: window groups

[martin rudalics]

> Could you describe the purpose of the window groups feature
> in a few lines of English?  If the feature does not have
> a simple conceptual description, it is not a good feature.

Window groups provide an abstraction of Emacs' internal windows.  By
design, internal windows (with the exception of `frame-root-window') are
not accessible to Elisp functions and cannot be manipulated directly by
them.  Window groups enable Elisp functions to access and operate on
internal windows in a clean and safe way.

As a consequence, Elisp based window managers can specify and manipulate
the layout of an Emacs frame by operating on collections of windows on
that frame rather than on single windows.  Typical needs of such window
managers are:

- Subdivide an Emacs frame into multiple areas (typically an "edit area"
  and one or multiple "view areas") thus specifying the basic layout of
  a frame.

- Assert that layouts change in a conceivable way.  For example, buffers
  visiting files should be always displayed in the edit area, the
  "compile window" should always appear below the edit area, other
  applications should not be allowed to change the layout of the edit
  area or the view areas.

- Make it possible to save layouts and restore them later.  For example,
  restore a layout in the same or a different frame, or in an arbitrary
  window of a frame.  It should be also possible to save layouts to a
  file and restore them from there in this or another Emacs session.

> Using a number to designate each group is un-Lispy.

The only use of group numbers currently is to provide the second
argument for the function `clone-window-configuration' since I wanted to
avoid that applications must keep a reference to deleted windows.  In
all other cases applications are supposed to reference a window group by
specifying a visible window belonging to that group.

Technically, group numbers get assigned like window numbers.  It would
be possible, albeit inefficient, to avoid using numbers: Some group
identifier must get stored together with each window-configuration.
When creating a new group, we would always have to scan all stored
window configurations to find out whether a group with that id already
exists.  Otherwise, a `set-window-configuration' could violate the
invariant that group ids must be unique.

> It seems unclean that the group disappears if you happen
> to reduce it to just one window.

Currently, an invariant requires that group root windows are internal
Emacs windows.  Hence `delete-window' automatically dissolves a group as
soon as it has one visible member.  I suppose it wouldn't be difficult
to relax that invariant.

>     - 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.
>
> I cannot follow why this does the right thing for them.
> Can you explain?

One of the problems of integrating ECB into Emacs is to avoid that
"other" Emacs operations interfere with those of ECB (where other
operations include popping up a *help*, *info*, or *backtrace* window).
By default `display-buffer' does not invoke `split-window' with GROUP
set to t - hence these windows always appear outside the rectangular
ares reserved for group windows.  The same holds for any application
that is not aware of the group the selected window belongs to.

On the other hand, applications based on window groups must be group
aware.  This means they can always invoke `split-window' with GROUP set
to t to add the new window to the group the original window belongs to.

Interactively, `split-window-horizontally' and `split-window-vertically'
would call `split-window' with GROUP set to t iff WINDOW is part of a
group.  Similarly, `delete-window' would always select a window of the
same group as the deleted one, `delete-other-windows' would delete all
other windows of that group, `other-window' move to another window of
that group, ...