Re: Window configurations

[martin rudalics]

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

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.

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

Some window managers are tiling window managers, even Windows XP has one
built in.  So even if Emacs permits overlapping windows it will probably
still offer tiled frames too.

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

Hmm ... windmove never helped me that much.  I rewrote the core function
for my own purposes because there are windows I never want to select
interactively but the window behind such an unselectable one (or on the
left or right of it) is the window I really want.

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

I have one buffer type which gets killed as soon as it's not shown in
any window.  Another one gets its name from the name of the window it's
shown in.  But I admit that in most cases the problematic issue is not
the buffer itself but the major or minor mode a window's buffer is in.

I suppose the solution is to (1) make the mode take care of saving the
relevant information and (2) untie buffer and window management in some
way.  How this would work for edebug, GDB, or diff sessions is currently
beyond my imagination.  Note that all I'm concerned here is that we now
should probably fix the order in which the restoring steps are perfomed
and what impact that has on restoring window configurations.  Whether
and how modes can be fully restored would be left to their designers.

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

I never looked into this but I'm surprised that Info buffer would work
out of the box.  Do help buffers work well too?

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

I recall that Lennart tried to do that.  Currently, overlays can be a
mess after reverting a buffer so I think there are more important things
to do first.  Maybe we could try to handle this by giving windows fairly
unique print names.

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

Probably at the expense of deleting windows when the frame gets too
small.  But my point was only that we have to process buffer-local
variables _before_ resizing frames.

martin