Re: Add function to rotate/transpose all windows

[martin rudalics <rudalics@gmx.at>]

 > 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

	     (cond
	      ((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))))
	      ((window-left-child window)
	       (cons (cons nil window)
		     (cons (cons (window-normal-size window nil)
				 (window-normal-size window t))
			   (window-tree-pixel-sizes
			    (window-left-child window) t))))
	      (t (list window (cons (window-normal-size window nil)
				    (window-normal-size window t)))))
	     list))

so the cons arguments pair up.

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

But we have to keep the full explanation of the argument in the commands
and also say there what rotating 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."

(defun window--window-to-transpose(frame-or-window)

needs a space before the argument list.

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

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

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

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

Not really.  Let's do that in the manual.  It will become hard enough.

martin