Re: Infrastructural complexity.

[Thomas Lord]

On Sat, 2009-07-18 at 13:11 -0400, Richard Stallman wrote:
> A "windowgroup" is similar to an Emacs frame, inside another emacs
>     frame. I like this better than using several Emacs frames.
> 
> It might be a subtle question.  To think about it, I suggest looking
> at by asking: What is the difference between a windowgroup and a
> framelet?  Or what are the various differences?
> 
> With a list of these differences, it might be possible to see a number
> of different design options and what is better or worse about them.

It is hard to be objective because it is an
apples and oranges comparison.  I won't pretend 
to be but I'll try to not be unfair.

One difference is that the window groups proposal
changes the behavior of windows by quite a lot.
I have trouble (perhaps its just me) thinking 
through all the implications of what, for example,
the changes proposed for "split-window" imply.

On the other hand, framelets changes the rules for 
frame handling just a little.  They seem far easier
to think through, to me.

Window groups includes new rules for "split-window" that are
hard to wrap one's head around.  It's clear (sorta)
that the new rules can be used to achieve the desired
IDE-style features but it isn't clear what else the
new rules imply.   I get pretty confused just reading the
window groups proposal.

Framelets says that you can have five frames in a window
system window plus any pop-ups or tear-off menu frames
associated with that window.    One of the five frames in
a window is the "parent" frame to all the others - the main
edit area.   Four of the five frames are laid out along the
periphery of that main edit area (there are 16 ways to do
so) - and they are for "control panel" interfaces that are
common in contemporary GUIs.  Finally, you can create free-floating
child frames like "tear off menus" that are common in GUIs.

Not a lot of details of how frames work change.  A framelet
mostly works just like a frame does today.   Some differences
are that if a parent frame is hidden or destroyed, it's child
frames go with it;  new code can ask "does my selected-frame
have a parent and if so, what is it?".  The window subsystem
of Emacs is unchanged.

Framelets seem a much cleaner and simpler and less restrictive
in future work yet solve the IDE goals of the present.

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.


-t