Re: Infrastructural complexity.

[martin rudalics]

> Why would you change `next-window'?  Is it
> that you want C-x o to jump from edit area
> windows to control panels and back again?

`next-window' has a MINIBUF and an ALL-FRAMES argument.  I'm not sure
whether and how their semantics would change with nested frames.

>>  >>  decide how they are allowed to
>>  >> tile a frame
>>  >
>>  > Yes.  I have one possibility that seems to cover
>>  > all of the use cases people commonly want, but
>>  > there are other ways to do it, certainly.
>>  >
>>  >> (which would be mostly a copy of the window making,
>>  >> splitting, and deleting code)
>>  >
>>  > Maybe.  There are other possibilities.
>>  > It could also be done with something like
>>  > the layout engines found in some GUI
>>  > toolkits.
>>
>> These would have to be rewritten and adapted accordingly.
>
> It shouldn't be very much code.

Fine.  This might also help frame resizing code DTRT in general.

>> But what would
>> `window-frame' return?
>
>
> The containing frame(let), just as it does
> now.   Control panel modes - for use in
> buffers displayed in control panels - can
> use a new function in some cases:
>
>     (defun window-parent-frame (w)
>        (if (frame-parent (window-frame w))
>             (frame-parent (window-frame w))
>           (window-frame w)))
>
>
>
>>  What would the `frame-root-window' of the
>> `window-frame' of a window be?  Or `selected-frame'?
>
> The root window of the frame, just as it is
> now.   Control panel modes could use, in some
> cases, (frame-root-window (window-parent-frame))

Maybe it would be simpler to call framelets just frames and the "outer"
(nil-parent) frame something different so there would be no changes in
the naming conventions.

martin