Re: Add function to rotate/transpose all windows

[Pranshu Sharma]

martin rudalics <rudalics@gmx.at> writes:

>> Right now, I feel the code is in a pretty complete state.
>
> Let's try to polish it up a little so it becomes easier to read.
>
> The doc-string of 'window-tree-pixel-sizes' should be updated.  Maybe it
> should be renamed to 'window-tree-normal-sizes' too.  Also, the repeated
> consing somehow obscures the fact that you are constructing a list for
> each window.  So I would write, instead of
>
>             ((window-top-child window)
>              (cons (cons t window) (cons (cons (window-normal-size window nil)
>                                  (window-normal-size window t))
>                            (window-tree-pixel-sizes
>                             (window-top-child window) t))))
>
> something like
>
>             ((window-top-child window)
>              (list t window
>                    (window-normal-size window nil)
>                    (window-normal-size window t)
>                    (window-tree-pixel-sizes (window-top-child window) t)))
>
> You obviously would have to make sure that my interpretation of your
> code is correct.

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

> In the commands I wonder whether the SUBTREE argument is necessary.
> Couldn't we simply say that FRAME-OR-WINDOW defaults to the parent of
> the selected window if it exists and to the selected frame's root window
> otherwise.

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.

>
> 'cycle-windows' is still a mystery to me.  I think we must first make a
> clear distinction between windows and the buffers they display here.  So
> far there was no need for that since "window A" meant just the window
> showing buffer A or the parent window A.  That is, we silently assumed
> some sort of identity mapping between window and buffer names.

The problem with this is that that the buffers of the windows are not
changed, rather only the windows, so this would be technically inaccurate.

>
> 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.

> 'fwin' should become 'first-window' since "f" alone could be taken for
> "frame".  And instead of 'selwin' I'd write 'selected-window'.  Also
> writing 'win' instead of 'window' is hardly ever a "win" in my
> experience.

Ok, I ended the win streak.

>           (mapc 'window-make-atom atom-windows)
>
> could be a bit of a problem (it assumes that 'window--atom-check' has
> done its work in between) but let's leave it alone for the moment.

split-window calls window--check which calls window--atom-check, so I
think it's fair to assume window--atom-check has been called.  And if it
hasn't then it shouldn't change anything iiuc.

> I think these have become obsolete now.

I kept the flen one as it's still in use.

> is a very uncommon thing to do.  Can't you use a lambda here?

Turns out it was uncessasary, before I needed it for something so I
could set it's value before bidning aditional stuff, not I just moved it
to the start of the BODY block of the let.

>   The words that for me fit these meanings are
>   transpose-window-layout and rotate-window-layout.

Ok, done I changed the names.  But so far I can't come up with a
docsting that will also be tehcnicaly correct(can't do the buffer change
windows same route), and also understandable.

I think the best way would be to explain visually, as Juri suggested.
Is it fine to include ascii art in docstrings?

window-transpose.el
Description: application/emacs-lisp