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

>>> - might fail with atomic windows
>>
>> What's an atomic window? I read the manual but still couldn't
>> understand>> And always keep in mind that once our functions exist,
>> people will use
>>> them on-the-fly, expecting them to "just work". They won't forgive
>>> the
>>> smallest misbehavior.
>>
>
>
> An atomic window is a parent window - considered the root of the
> atomic window - such that all its descendants have the 'window-atom'
> parameter set to t.  'split-window' when called with any of these
> windows as first argument makes the new window always on a side of the
> atomic window.  With other words it splits the root instead.  Also,
> deleting one of these windows deletes the root instead and deleting
> all other windows deletes all other windows but the root.
>
> The idea of an atomic window is that although it is build from
> internal and live windows, it behaves like a live window for the
> operations mentioned above.  It's the smallest unit for them and you
> cannot split it just like you cannot split an atom chemically.

I see, it's a good idea.  Sadly `gnus-use-atomic-windows' does not work
when horizontal and vertical splits are mixed, probably going to report
this bug later, but as am emacs user and therefore denier of
multithreading, I'll wait till this is resolved first.  But I got to
admit, this was probably not the best name, but then again I can't think
of a better name.

> I added a 'no-rotate' parameter that can be used for atomic windows so
> they do not rotate inside.  But I have not tested it well yet.

I cannot imagine this going well at all, but I'll test later.

>>> - doesn't care about fixed size windows
>>>
>>> - might fail with small windows.
>>
>> Highly unlikley, I tried it with very small splits and it worked.
>
> Note that I've bound 'window-min-width' and 'window-min-height' to
> zero.
> 'split-window' will automatically choose the nearest admissible size
> but
> it will fail in a trivial case where you do say a couple of C-x 3 in a
> frame that is 80 columns wide but only two lines high.  Hopefully the
> 'condition-case' will catch them all - precalculating sizes and
> rejecting a rotate when they do not fit would be no fun.

How about setting a window configuration, then splitting the window, and
it goes boom-boom,  we can just revert to that?

>>> The latter two probably mean that we should run the algorithm with
>>> fixed sizes and minimum window sizes in place first.  If
>>> 'split-window' complains, re-run the algorithm ignoring fixed-size
>>> windows and minimum sizes.
>>
>> What is the expected thing to happen in fixed size windows?
>
> That they do not change their height, width or both however you rotate
> them.  If you do say C-h f setq and you have 'temp-buffer-resize-mode'
> turned on, Emacs will try to resize the help window and later changes
> of
> the window structure will usually try to keep the size of the help
> window fixed, if that is possible at all.

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?

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.

>> ngl, when you say it like that it sounds like I am making food for a
>> kim
>> jong ung
>
> It's more like making a diet plan for him.

If I was Kim, I wouldn't mind some extra ice cream at the cost of just
another kg