Re: Window configurations

[martin rudalics]

> Do you plan to create a branch for your rewrite of window.c?
> It would be very interesting to look at it.

I have to catch up with recent developments on the trunk - currently I'm
at revision 99248.  And I yet have to write Change Logs.

> No, I don't use `split-window'.  I use exactly the same algorithm as in
> `set-window-configuration', and additionally make new windows.
> In my tests, this works correctly.

That's what I intended to do when I first looked into this.  Making new
windows essentially has the problem that when, for whatever reason,
coordinates are garbled, you end up with a distorted frame and, in the
worst case, crash Emacs.  Checking window edges is simple with an
existing window tree.  But if you build the entire tree from scatch, you
also have to provide a safe way to GC windows you made just in case they
don't fit.  With `split-window' you always add one window at a time and
you never make a new one unless you're sure it fits.

By no means I want to talk you out of this ;-) but `split-window' is a
socially well-established function.  Saved window configurations will
hardly ever get used that much.  And we'll already have a hard time to
maintain compatibility, for example, when you want to restore a
configuration saved by Emacs 27 in an Emacs 29 session (or vice-versa).

>> That said, the *entire* coordinate information of a particular window in
>> an EWC would consist of (1) whether it is a horizontal or a vertical
>> combination and (2) the proportional space - either a float or the
>> fraction of "some largest integer" - occupied by the window wrt to its
>> parent window.
>
> Currently `set-window-configuration-from-sexp' works without these
> parameters.  But maybe they would be useful for user-defined window
> configurations.

Users "define" window configurations by splitting and deleting windows.
They have no idea of the underlying window tree.  But if you don't use
`split-window' storing the type of window combinations doesn't make
sense anyway.  It's just that current window configurations have lots of
redundancy: For a vertical combination, the widths of all subwindows are
the same as that of the parent window, top-lines can be calculated on
the fly by adding the top-line of the left sibling to its height, ...

Anyway, the greatest problem IMO is to get windows correlate with their
buffers.  I don't think that restoring ediff configurations will become
ever feasible (unless you build this into the ediff code) and I'm also
pessimistic about Info buffers - in particular cloned ones.  And
obviously we'll fail to handle code based on window objects or overlays
with a window property.

But for merely "normal" buffers the integrity of buffer-local variables
affecting size and appearance of windows displaying them must be
preserved.  For example, when a buffer has `window-size-fixed' non-nil,
any frame resizing step in your `set-window-configuration' should keep
the size of the window fixed.

martin