Re: window groups

[martin rudalics]

>>I know XEmacs does that.  However, over the past two weeks I was able to
>>crash Emacs more often than over the past two years.  Practically all
>>these crashes were due to malformed window-trees.  Hence I suppose
>>exposing internal windows to Elisp might make it possible to crash Emacs
>>from Elisp quite easily.
>
> I guess that would be an advantage of Joakim's approach, which works
> more "on the surface".

I got most of these crashes when restoring window trees from the
structures stored in save_window, in particular from the values stored
in the parent and prev fields.  This task is fairly easy when you're
allowed to change the window field of saved_window directly as in
`set-window-configuration'.  It's tricky when you use make_window to
make a copy of the window as `clone-window-configuration' does and the
window field still has to refer to the original window (dead or alive).

Anyway, if you want to clone window-configurations from the structures
created by `current-window-configuration' you probably won't be able to
stay any longer "on the surface" ;-)

> I'm not sure I understand enough of those problems and of your proposal
> and Joakim's to understand how one proposal would make it easier to
> address those situations.

If a window group is identic to an internal window of an Emacs frame,
you can write down all invariants you need in a couple of lines.  As a
consequence, you can rewrite the window management code (`split-window'
and `delete-window' mainly) and devise any new routines quite easily.

If window groups are allowed to comprise arbitrary windows or you don't
check that applications maintain a one-to-one correspondency of internal
windows and groups it's IMHO much better to _not_ touch the windows
management code and leave alone the current advice mechanism of ECB.