Re: Add function to rotate/transpose all windows

[pranshu sharma <pranshusharma366@gmail.com>]

martin rudalics <rudalics@gmx.at> writes:

>> The following code implements transpose-frame and which works fine, I
>> tested with some random window layouts and it worked for all.  It uses
>> the split-window refer argument.
>
> Thank you.
>
>> (defun transpose-frame (arg)
>>   "Transpose frame, or if arg is non-nil, selected window."
>
> ARG (upper case please) should be renamed to make it more descriptive
> and you should explain what transposing the selected window means.

Ok, will do

>
>> 	     (res (deepmap (lambda (e) (if (windowp e)
>> 					    (prog1 (cons e (window-edges e))
>> 					      (unless (equal fwin e)
>> 						(push e delist)))
>
> IIUC here you "flatten" the return value of 'window-tree'.  Why do you
> do that?  Can't 'transpose-frame' work directly on the return value of a
> (possibly modified) 'window-tree'?

This is definetly a big hack.  The reason why this is needed is
because the parent window might not actually be a window, it might also
be another split, so it would have to recursivly descent find the first
window.

The only real alternative I can see is that if toggle-window-split
returns a list of spltis to do, and then they are mapped over and done
by toggle-window-split one level higher.

I'll look into how transpose-frame.el deals with this.

>>					    (prog1 (cons e (window-edges e))
>
> On my maximized frame calling 'transpose-frame' repeatedly shrinks the
> right/bottom windows until they cannot be shrunk any more.

Hmm, show your window-tree (or the sequence of splits you did), I tested
with a lot of splits and didn't find this problem.

> I wouldn't use 'window-edges' here.  Make your own version of
> 'window-tree' (or give that an optional argument) so it returns the
> normal sizes of windows instead of the edges and use the normal sizes
> as factor for the SIZE argument of ‘split-window’ and make the
> PIXELWISE argument non-nil.

I see, this should definetly make the function better.

> Rounding window sizes can be awfully tricky and we should try to avoid
> its effects as good as we can.  When transposing windows on a GUI you
> will always have to take into account that the width of a window
> includes things like fringes and scroll bars (where the size of the
> latter is toolkit dependent) which often make the width not an integral
> multiple of the frame's character width.  A similar argument goes for
> window heights, for example, if a mode or tab line is displayed with a
> different font or some sort of box around it.
>
> Also I expected your functions to run on subwindows of a frame's windows
> and permit to rotate configurations clockwise or counter clockwise as
> the version from 2011 did?  Do you intend to provide those?

They should be very easy(just changing up the arguments of split-window
to correct combo of above, below, right, left), I'm just
trying to first get the other aspects streamlined, but yes, I do intend
on adding them.

I'll also add flip if you want.

>
> martin