martin rudalics <rudalics@gmx.at> writes:

> or its orthogonal variant.  With your approach I do not see (a (c d))
> after the second split but (a (b c)) just like with mine.  AFAICT your
> algorithm performs exactly the same sequence of splits as mine.  You can
> verify my claim by putting a 'y-or-n-p' after each 'split-window' call
> (in the version I attached they are commented out in the code), making
> two frames on your screen and stepping through your version in one and
> mine in the other window.  You will see that they split windows in
> exactly the same order.

Yes, I veryfied that and it is true

> I also noted that with
>
> C-x 3 C-x o C-x 2 C-x 3 C-x o C-x 2
>
> my and your last 'split-window' call split a parent window - something
> you earlier told me that you didn't want to do.

I quicly changed my mind after saying that, seeing there was no proper
alternative rather than my first approach.  But looking at your
'top-level' first approach you mentioned later, seems like there might
be a way.

> The following is the central idea of my approach.  Suppose F is a first
> live window (initially the 'frame-first-window') - a live window which
> has no previous sibling in the window tree.  And suppose P is the parent
> of F in the window tree that has already been deleted, all relationships
> are from the tree before it has been deleted.  'delete-other-windows'
> now deletes all windows but F.
>
>   P
>  /
> F   P1    P2 ... Pn
>    /     /      /
>   /     /      /
>  F1    F2     Fn
>
> Now I take the next sibling P1 of F - I assume it's a parent window
> because that's the hard case.  I find the first live descendant of P1
> which is F1 (any parent window invariably has such a descendant).  My
> first split is now
>
> (split-window F .. (F1 . P))
>
> because I see that F has not yet its valid parent P.  This resurrects F1
> and makes F and F1 the children of the resurrected P.  If F already had
> its valid parent P, I would have called
>
> (split-window F .. F1)
>
> and P would have got the additional child F1.  Now I recurse with F1
> taking over the part of F.  After I'm done with the entire subtree of
> P1, I do
>
> (split-window P1 .. F2)
>
> so P gets a new child window F2 and continue with F2 taking over the
> part of F1 and F.  After I'm done with the subtree of Pn, I continue
> with P's next sibling and go up until I arrive at the root of the window
> tree.
>

> Note also that I always apply the new size to the window I split.  This
> means that when I split F then F1 initially gets the entire remainder of
> the size of P.  It also means that when I later split P1, 'split-window'
> has to recursively resize the entire tree rooted at P1 and F2 gets the
> rest of the size of P - that of P minus that of F and P1.

Yeah, my approach did the same thing as this. The alternative is to
reverse the list and split them with size negated from root window,
but this gets very bad very fast.

> It might be interesting to try the following variant: Instead of
> recursing immediately into F1, first split all siblings of F so that one
> has a layout of
>
> F  F1  F2  ... Fn
>
> and only now recursively process F1, F2 ... Fn.  This would have the
> advantage that when splitting F1 to fit in the entire subtree rooted at
> P1, its size is already the final size.  And we might not have to split
> parent windows either.  But such a solution will be less trivial to
> code.

this idea seems pretty good, I don't see any downside to this.  I'll
have a go at it.  But will this work with your earilier magic patch that
would somehow automaitclly reconsutruct parent windows?

> Attached find my latest diffs (the documentation has not been completed
> yet) and window-rotate.el.

I applied the patches, and found your think works well in most cases,
however it fails to work in windows of file attached