Re: Infrastructural complexity.

[Thomas Lord]

On Thu, 2009-07-23 at 11:24 +0200, martin rudalics wrote:

>  > Did I misunderstand something?
> 
> Not at all.  Only window groups are guaranteed to form rectangles.  I
> never claimed that the remaining windows would add up to a rectangle.
> And obviously you can't retrieve the remaining windows by calling
> `window-list'.  You can subtract the windows in a window group from the
> windows returned by `window-list' to get the "remaining" windows.

That's a fine example of how window-groups
are not quite the right concept here.

I understand you to say that `window-list'
should (by default) return all of the windows,
grouped or not.   That won't DTRT in the use
cases of greatest interest - where "groups"
are supposed to be control panels around an
edit area.   Just the windows in the edit area
should be returned by default.

That is, it seems to me - and yes this is 
necessarily just an opinion about user 
interfaces - that the edit area windows 
should behave exactly like a traditional
Emacs frame.  For example, C-x o navigates
(normally) just among the edit area windows.
Normal splitting or deleting of a window changes
only edit area windows.  Programs that look for,
say, a largest window to use to pop up some
buffer should look only to the edit area (unless
explicitly written to do otherwise).  It should
take a special gesture (keystroke or mouse, different
from C-x o) to select a window in a control panel
and, once its selected the set of windows in that
control panel are then the focus (the C-x o ring,
etc.).

Emacs already has a way to segregate groups of
windows in that way: frames.   That's what
gives rise to the idea that control panels are
mostly just a new way to render certain frames.




-t