Re: Infrastructural complexity.

[martin rudalics]

>> I'd consider a primary frame an artifact useful for tiling and for
>> giving the window manager something with a title, a menubar, and a
>> handler for resize requests to play around.  Nothing more.
>
> I think a primary frame should also have the "edit area".
> That is, not every Emacs window exists within an "attached
> frame" - some exist within primary frames.

It wouldn't be too difficult to make Emacs windows only exist within
"attached frames" aka as frames.  The "primary frame" aka as something
that isn't even called a frame would then simply serve as container for
at least one and sometimes more attached frames.  Whatever we have to
pay for this in storage space can be made up by the fact that if we
implement both primary and attached frames within the current frame
concept, many slots in a frame structure (like glyph pools and matrices,
face caches, and the like) remain _conceptually_ unused for one of them.

> That's based on the use cases for these features.
> The "edit area" conceptually corresponds to the frame
> which represents the entire window system window.
>
> For example, if an elisp programs hides the selected
> frame and the selected frame is a control panel, then
> just that control panel is hidden.

I suppose hiding a control panel would affect the appearance of the
containing primary frame.

> If the program
> hides the frame from the edit area, that should minimize
> the window system window and thereby effectively hide
> all attached frames (control panels).

That would be the simple case.

martin