Re: Window configurations

[Juri Linkov]

> 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).

I agree that when designing this feature, we should think about the future.
Let's imagine that Emacs 27 will switch from the tiling window manager
to an overlapping window manager.  Then `split-window' in window
configurations will make no sense.  This suggests that for the generality
window configurations should be defined as a list of windows with their
parameters, i.e. very much like frames are defined now.  Frame parameters
to define the frame geometry are `left', `top', `height', and `width'.
Window parameters to define the window geometry are `left-col', `top-line',
`total-lines', and `total-cols'.  Perhaps, in an overlapping window manager
they should be in pixels.

> 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, ...

Yes, currently window coordinates are redundant because of the
limitations of the tiling window manager.  So we have to find a minimal
set of window parameters to define the window location.  I agree that
a window tree is an implementation detail and users have no idea of the
underlying window tree.

Another variant is to define window geometry relative to the neighbor
windows, e.g. `left-window', `right-window' in terms of the package
windmove.el.  Such window configurations would be easy to define for users.

> 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)

I see no problems with window-to-buffer relations.  They can be defined
using buffer names.  This works successfully with desktop.el from the
x-tabs branch by saving and restoring window configurations in the
desktop file.

> and I'm also pessimistic about Info buffers

Window configurations with Info buffers are saved and restored
successfully in the desktop file as well.

> - in particular cloned ones.

What problems do you see with cloned Info buffers?

> And obviously we'll fail to handle code based on window objects
> or overlays with a window property.

Maybe a package that uses window overlays should use a new hook
to restore window overlays after a new window is created from
a window configuration.

> 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.

It seems the frame resizing step in `set-window-configuration' already
keeps the size of the window fixed.

-- 
Juri Linkov
http://www.jurta.org/emacs/