Re: Infrastructural complexity.

[martin rudalics <rudalics@gmx.at>]

 > I'm pretty concerned about the impact window groups
 > have on existing abstractions.

None, hopefully.

 > For example, if groups
 > are used as "control panels" then they probably should
 > not be reachable by C-x o;  `next-frame' is more appropriate.

Keybindings are not part of the window group concept but of ECB.  Emacs
without ECB (or some other UI) continues to work as if there were no
groups at all.

 > I'm not sure there is a good answer to whether or not window
 > group windows should appear in the return value of `buffer-list'.

You mean `window-list'?  They won't appear there because this function
returns only life windows.  There would be an extra function that gets
you all active window groups.

 > I don't think window groups should resize the same way as
 > non-grouped windows when a non-group window is deleted.
 > I think the presence of window groups will make it more
 > difficult to improve the window configuration code.

Resizing windows must be rethought anyway.  Fortunately, window groups
do not add any additional complexity here.  Emacs worked with leaking
internal windows for quite some time.

 > Framelets have none of those problems.

But they don't solve the window resizing issues either ;-)

 > At no time, therefore, is there a need to change
 > the window property of overlays.

There is if we pretend that tearing off a window stands for "moving that
window from one frame to another".

 > Saving and restoring window configurations is a separate
 > question entirely.   The "window property problem" does
 > come up again there, I guess.  Perhaps the solution for
 > that is to allow windows to have an "ID" slot which may be
 > bound to a symbol, and allow the window property of an
 > overlay to be a symbol which may or may not mach the vale
 > of "ID".

This could work indeed, as well as some other form of aliases.  But I
don't want to think of specifying that.

 > Suppose that every frame and every Emacs window had (optional)
 > menu, toolbar, and tabbar lines.  These can be understood as
 > all variations on the same thing: they are a GUI interface to
 > current keymaps.   These optional lines could be on any of the
 > four edges of the window or frame.

Unfortunately bars are not lines, they vary in size and shape and create
all sorts of troubles for the display-engine.

 > Then a natural way to have "separate" forms of those is to
 > permit the creation of a detached framelet (a frame with
 > non-nil parent) and permit it to contain a single, 0-width
 > or 0-height Emacs window - so that the menu, tab, or tool-bar
 > is the only thing visible.

Just that the display-engine is not very good at displaying
0-width/0-height objects.  The window code has special checks to avoid
that windows get too small.

 > As a side effect of that design there would be a neat
 > feature possible:  the 0-width or -height window could
 > be made non-0 width/height for the purpose of displaying
 > help text.   For example, typing C-h k and then mouse-clicking
 > on a toolbar icon could temporarily expand the invisible
 > window (making it visible) and put the help text there.

I'm afraid I'll have to add 0-size windows to the list of objects that
require a frame-based solution.

martin