Re: Infrastructural complexity.

[martin rudalics <rudalics@gmx.at>]

 > 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.  I sympathize with that
 > but I think that the proposed complexity in core lisp code
 > is sufficiently problematic that it's at the very least not
 > an obviously good idea to go with window groups.

I'm afraid that window groups won't get away with little or 0 changes to
the C code.  OTOH, framelets could get away with hardly any changes to C
code.  Speedbar has its separate frame, initially attached to some
existing frame, can be torn off and moved around.  There's no reason why
we can't additionally build around an existing Emacs frame a message
frame, a log frame, a tools frame.  All these would come (optionally)
with their own tool bar, menu bar, tabs, mode-/header-line and could be
handled by the window manager of your choice.  The display code might
need some additional means to handle zero sized frames or windows, but
that's all IMHO.

Personally, I prefer to always stay within one and the same frame and
therefore never use the speedbar.  So in practice I probably would never
work with code based on distinct frames.  Maybe also, converting
existing ECB code by substituting windows with say root-windows of
frames might be difficult but likely no more than making it work with
window groups.

martin