Re: Add function to rotate/transpose all windows

[Pranshu Sharma]

martin rudalics <rudalics@gmx.at> writes:

>>> IIRC I fixed that earlier by binding 'window-combination-limit'
>>> appropriately.
>>
>> I still wasn't able to get it work using that, but what I think will
>> work is `window-combination-resize'.
>
> This won't do what you want - it will simply give all windows the same
> relative size, something 'balance-windows' does.  But you want to
> preserve the relative sizes of windows.  Try with my algorithm - it
> preserves proportional sizes quite well.

I see, I don't quite get how your algorithim works, so I'll just use the
reverse list and split at root window approach which also works.  They
should have same result, but this one will have less moving parts.

>
>> It is simply not possible then to rotate or transpose windows if they
>> are fixed size, imagine a fixed size top level split function, how would
>> that get rotated?
>
> Emcas ignores the fixed-sizeness when it has no other choice.  Like when
> you delete a window and the only remaining window on the frame is of
> fixed size.  But first of all flipping windows should always preserve
> fixed sizes.  And rotating windows should at least try to do that.
>

Flipping windows won't change the size using the current approach, but
the window will be split to match it's old height, idk if that will give
bug or not.  I would rather it just simply doesn't work with fied
windows, instead of confusing the user who probably doesnt even know
emacs has fixed windows.

>> I think maybe we can do a map windows at the start to check if any are
>> fixed size, and if yes then we stop.
>>
>> So so far, my game plan is I won't do any of the window alist stuff,
>> rather just the normal window-pixel-tree but include internal windows as
>> well.
>
> The alist approach has one decisive advantage: When you later find out
> that you would like to know a specific window property before you delete
> windows you can simply add that property.  With the pixel-tree approach
> you will have to add it to the pixel tree and get one "a" more in the
> ca..rs you use for accessing the tree's elements.

wdym by the last sentence?

Using my approach, I will anyways be able to modify the return value of
window-pixel-sizes while checking for fixed size windows, but it
probably won't be in alist form.  This will allow me to lose the helper
functions like window-alist-parent.

Also, the only thing I'm checking for is if a window is atomic and fixed
size, right?

to check the fixed size, I'll just use window-fixed-size-p, and to check
if atomic (window-parameter window 'window-atom).

I think the window atomic facility should hve more interactive commands,
can imagine it being quite useful.