Re: Window configurations

[Juri Linkov <juri@jurta.org>]

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

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

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

But none of these window managers define tiled windows as a split
window tree.  So probably an Emacs' overlapping window manager
will not be based on window trees.

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

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

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

No, help buffers don't have an addressing scheme like in Info
with (info "(file)node").  Recently I proposed to display
Help information in the Info reader.  This will save and restore
buffers with Help information in the desktop file.

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