Re: Add function to rotate/transpose all windows

[Pranshu Sharma]

martin rudalics <rudalics@gmx.at> writes:

>> The problem with this is that the reutn would be:
>> (nil/t win height width (w1 w2 w3))
>> instead of:
>> (nil/t win height width w1 w2 w3)
>> So I slightly modified your code
>
> It has become worse, sorry.  Please revert to the previous code but
> format it better as
>

If your problem was with:

`(nil ,window
            ,(window-normal-size window nil)
            ,(window-normal-size window t)
            .
            ,(window-tree-normal-sizes (window-left-child window) t))

I changed it to:
               (append
                (list nil window
                         (window-normal-size window nil)
                         (window-normal-size window t))
                (window-tree-normal-sizes (window-left-child window) t)))

Do you still want me to go back?

>> Ok, I did something similar, the problem with your idea was that if it
>> default to parent of selected window, then it wouldn't transpose the
>> frame by defualt, user will transpose frame much more than transpose a
>> subsection.  The change I made makes it so that is works as before, but
>> without subtree and with the extra functionaility of being able to pass
>> a numric arg which will determine how {opposite word of deep here} of
>> windows to transpose.
>
> The numeric argument is too difficult to explain - hardly anyone will
> know what even the second ancestor of a live window is.  So I wouldn't
> do that.  Maybe a numeric argument could be useful to rotate by 180 or
> 270 degrees.

This would only be applicable to rotate commands, but
window--window-to-transpose is used for all the commands.

the ancestor thing will be useful, it's worth at least attemptign to
explain.  

> But we have to keep the full explanation of the argument in the commands
> and also say there what rotatinig etc. means.  Something like:
>
>   "Rotate window layout anticlockwise by 90 degrees.
> Transform the layout of windows such that a window on top becomes a
> window on the right, a window on the right moves to the bottom, a window
> on the bottom moves to the left and a window on the left becomes one on
> the top.
>
> If FRAME-OR-WINDOW is nil, rotate the main window of the selected frame.
> If FRAME-OR-WINDOW specifies a live frame, rotate the main window of
> that frame.  If FRAME-OR-WINDOW specifies a parent window, rotate that
> window.  In any other case and interactively with a prefix argument
> rotate the parent window of the selected window."
>

Fine, I'll do this once we sort out the behaviour of 
window--window-to-transpose.

>>> CONF, DO-NOT-CONVERT-SIZE and ATOM-WINDOWS should IMHO become
>>> lexically
>>> bound variables.  IIUC they are never altered within the body of
>>> 'window--transpose-1' and only clutter up the recursions.
>>
>> I 100% agree, but I don't know how to do this without dynamic scoping.
>> I tried `dlet', but that didn't work.  Only way I can think of is
>> nested
>> functions, which idk if you would want me to do.
>
> Once we have lexical binding we can use it.  On top-level do
>
> (defvar window--do-not-convert-size nil)
>
> in 'rotate-windows-...' bind it to nil and in 'flip-windows-...' to t.
> And in 'window--transpose-1' use it instead of 'do-not-convert-size'.
>
> But it's only a cosmetic issue so if you don't want to, don't bother.

Ok, I won't do this then, I don't want to clutter up the window-
namespace unless neccasary.

> When he wrote that Richard didn't know about 'cycle-windows'.  He
> probably meant to use 'rotate-window-layout-clockwise' and
> 'flip-window-layout-horizontally'.
>

Doing clockwise and anti clockwise would not neccasaryly be accurate, it
operats more like other-window, saying other-window-anticlockwise for
(other-window -1) would not be accurate.

Doc string of other-window:
  Select another window in cyclic ordering of windows.

This is why I think reverse makes the most sense techncially.

Also I fixed all of the byte compile warnings.