Re: Infrastructural complexity.

[martin rudalics]

> It doesn't sum to the size of the frame, that's true.
> Isn't it already the case, however, that the window
> widths and heights don't necessarily add up to the
> full size of the frame?  What are you worried about?

For example `window-full-width-p' is currently calculated as

#define WINDOW_FULL_WIDTH_P(W) \
  (WINDOW_TOTAL_COLS (W) == FRAME_TOTAL_COLS (WINDOW_XFRAME (W)))

This would fail with your approach when invoked on a window in the edit
area.  We'd probably have to redefine it by asking whether that window
is as wide as the root window of its frame.  But such things haven't
been investigated on a wide scale yet and we'd also have to cope with
the somewhat paradoxical situation that the root window of a frame is no
longer as wide as the containing frame.

You haven't yet sketched the details of how your approach would handle
things like `set-frame-position' or `set-frame-size'.  IIUC you have to
intercept these functions in some sense to handle the case where someone
wants to move or resize an attached frame.  I also have no idea how
functions that let a user resize attached frames with the mouse and how
mouse tracking in general will be implemented with nested frames.

For example, if in your

_______
|_|_|_|    template
|_|_|_|
|_|_|_|

I have the two attached frames named 1 and 2 as this:

_______
|_|_|1|    template
|_|_|2|
|_|_|_|

What happens if I "move" the imaginary border between 1 and 2 up or down
(provided I can do that at all).  Does that also resize the edit area?

Also an application might want to know whether the coordinates returned
by `mouse-position' refer to the upper-left corner of the edit area or
the primary frame.  If they refer to the upper-left corner of the
primary frame, we probably have to, for each primary frame, specify the
offset of the root window of that frame (the upper-left corner of the
edit area) in order to be able to determine in which window of the edit
area the mouse is (provided the edit area can be split).

OTOH how would `set-mouse-position' invoked on a primary frame interpret
its X Y arguments?  Could this move the mouse to an attached frame?

I understand that you are mostly concerned with user visible functions
like `delete-frame' or `other-frame' DTRT without changing them.  But
having `delete-frame' DTRT wrt whether its argument is the edit area or
an(other) attached frame is trivial.  If you specify that a primary
frame can't live without an edit area, it goes without saying that if
you delete the attached frame constituting the edit area, this will
delete the containing primary frame too.

Changing the underlying functions is the hard thing.  If you eventually
come up with a sketch of how you want to address issues like the ones I
sketched above I might be able to tell you more.

martin