Re: Add function to rotate/transpose all windows

[martin rudalics]

>> You would have to tell me in more detail what 'window-rebuild-tree'
>> would do.
>
> Say window window-tree-pixel-sizes retruns:
>
> ((t (918 . 562) (#<window 7 on *scratch*> (442 . 562)) (#<window 23 on
> *scratch*> (476 . 562))))
>
> Then if you C-x 1, and then:
> (window-rebuild-tree
>    '((t (918 . 562) (#<window 7 on *scratch*> (442 . 562)) (#<window 23 on
>     *scratch*> (476 . 562)))))
>
> It should rebuild the whole thing to the orignal

Yes.  That would be useful to (1) make a window state and store it
somewhere (2) arbitrarily alter the frame's configuration and (3) put
the state back into its frame.  It's obviously the same thing
'save-window-excursion' does but there's a twist: When a frame gets
deleted, you cannot restore the window configuration in it.
'window-build-tree' could do it and 'undelete-frame' could use it.  It
has one drawback: We can't collect the dead windows as long as the saved
state needs them.  BTW I have no idea why 'undelete-frame-mode' does not
try to resurrect a deleted frame as we do with windows.

>> One thing 'window-tree-pixel-sizes' should then possibly do is to
>> include the identity of internal windows so 'window-rebuild-tree'
>> could resurrect them as well.
>
> idk what you mean by this, is the identity not included in window object
> itself, as in does refer argument not work with it?

No.  Look at your your example above: All we know about the parent
window is what type of combination it is and what sizes it has.

> also I found that when using tabs from tab-bar-mode, calling functions
> like flip windows 2 times in a row will fuck up the tabs.

In what sense does it "fuck up the tabs"?

> I tested it
> with orignal transpose-frame.el and it does not have this problem, mayeb
> it is something to do with the C new patch refer argument code?

'tab-bar-mode' uses window configurations.  Maybe that's the cause.

martin