Re: Window configurations

[martin rudalics]

>> Sounds reasonable.  If we apply this idea today, the restore-from-sexp
>> step would decide how to rebuild the window tree from these geometry
>> parameters - that means how to nest windows into each others.
>
> For an overlapping window manager there is no need to rebuild the window
> tree from geometry parameters.  And for the current tiling window manager
> you said that window coordinates are redundant.

That's what I said earlier.  But if we eventually do need them for an
overlapping window manager, we could build them into the current tiling
manager.  Just that (IMO) the tiling manager needs internal windows to
work correctly.  So the common format would be your four standard
parameters left column, top line, height and width for _all_ windows
including internal ones.

The restore step for the current tiling manager would have to process
the internal windows and reconstruct the nesting by comparing their
coordinates with those of the leaf windows - just like the current
`set-window-configuration' does in

              if (!NILP (w->parent))
                {
                  if (EQ (p->total_cols, XWINDOW (w->parent)->total_cols))
                    {
                      XWINDOW (w->parent)->vchild = p->window;
                      XWINDOW (w->parent)->hchild = Qnil;
                    }
                  else
                    {
                      XWINDOW (w->parent)->hchild = p->window;
                      XWINDOW (w->parent)->vchild = Qnil;
                    }

where it sets the vertical / horizontal child of a parent window
according to whether the number of its columns equals that of its child
windows (this work by virtue of Emacs's ability to collapse matryoshka
windows although it might not harm much if for such windows the split
direction would be inverted).

The restore step for the overlapping manager would simply ignore
internal windows.  So we could restore configurations stored by a tiling
manager in an overlapping manager.

> That's why I proposed
> non-redundant and easy-to-define relative parameters.  I think it would
> be sufficient to have two relative position parameters `left-window' and
> `top-window' (that point to the left/top neighbor window) and two relative
> size parameters `width' and `height' (fractions relative to the frame size).
> I guess it would be possible to rebuild the window tree from this minimal
> set of window parameters.

Do you mean left would point to the left neighbor and top to the
neighbor above?  How would you assign them for a four window
configuration like this:

 -----
|1 |2 |
|-----|
|3 |4 |
 -----

Currently either 1+2 and 3+4 or 1+3 and 2+4 form internal windows.  How
would you convey that information with relative parameters?

> This looks like a new "intangible" window property discussed in the
> window-group threads.  Have you implemented this in your rewrite of
> window.c?

It's virtually impossible to do that in a strict sense (unless you go
for a `post-command-hook').  Note that you can always do a thing like
(select-window (minibuffer-window)).

What I've done is to make `other-window' by default not select certain
window types.  That default can be overridden by window parameters.  And
I wrote a `window-in-direction' function which does this for the window
in a given direction (I need this because I never use C-x o).

martin