Re: Infrastructural complexity.

[Thomas Lord]

On Tue, 2009-07-21 at 11:39 +0200, martin rudalics wrote:

>  > One large difference, though, is that framelets really require
>  > more changes to the C code of Emacs while window groups can
>  > get away with little or 0 changes to the C code.  From some of the
>  > conversation, I suspect that this is one of the big reasons that
>  > there is support for window groups.

> to state that IMHO implementing window groups means to make considerably
> more changes to the C code than implementing framelets.

OK.  I misunderstood and thought that the (supposed) lack of 
need for C code was an advantage of the window groups
proposal but apparently not.

I'm pretty concerned about the impact window groups
have on existing abstractions.  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.
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'.
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.

Framelets have none of those problems.



> Emacs has overlays which can have a window property which can have the
> display engine handle the overlay differently when the property matches
> the window the overlay is displayed on.  When you tear off a window the
> identity of that window changes and you have to check all overlays in
> all buffers whether any window property should get updated accordingly.

I don't think that that's the case.  "Tear-offs" don't 
mean that you can grab any Emacs window and move it to 
its own frame.   "Tear-offs" are more limited than that:

In something like the Open Office diagram editor there
is a toolbar at the bottom of the screen.  If you click
on an item in that toolbar - say the icon of a filled 
rectangle - it's a lot like a menu:  a small pop-up appears
with choices for which kind of filled shape you wish to
draw (rectangle, elipse, etc).   You can pick an item off
of that menu OR you can "tear it off" and have that 
menu remain permanently visible.   A natural model for this
in Emacs is that the pop-up menu is a frame(let) the whole
time.   At no time, therefore, is there a need to change
the window property of overlays.

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



>  > Since tear-off windows are not very important though, it doesn't really
>  > matter.  An implementation which creates a new Emacs window inside a new
>  > frame seems acceptable to me as well.  Or simply not having tear-off
>  > windows.

> ... or separate tool/menu/tabbars (unless the latter show up in the
> header lines).

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.

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.

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.

-t