AW: Infrastructural complexity.

[<klaus.berndl@capgemini-sdm.com>]

Without following the complete discussion i chip in now because ECB is mentioned and window-groups...

IMHO currently there is a "missing link" (well, probably not the right wording but currently i have nothing better in my mind) between a window and ist containing frame, namely the mentioned window-groups: a frame contains at least one window-group and a window-group contains at least one window.

Especially for applications like ECB this would be a great help because such IDEs devide the frame in several window groups (e.g. with ECB: one group contains the special browsing windows, one the editing-windows, one the compile-output-window) which in turn can contain arbitrary windows.

With such a window-group concept several things should/could be possible:
- preventing a group from being be deleted by C-x 1 (AFAIK currently
  there is something going on to achieve this with a new window-flag,
  IIRC implemented by Joakim for the next release 24.X?!)
- hiding (ie. deleting) a window-group (ie. all it's windows but no others
  from outside the group)
- saving the window-configuration of exactly one group and restoring only this
  window-group (if a frame allocates needed space)
- rewriting display-buffer so only a certain window-group can be
  used for displaying a buffer - or the other direction: a window-group can
  be prevented from being used by display-buffer for buffer display
- etc...

IMHO such a general window-group concept between the frame- and the window-
concept would alleviate writing a tool like ECB (and would make a lot of its
advices obsolete or at least much simpler)

This is the point of view of the author and maintainer of ECB ;-)

Maybe it's offtopic for the original thread (i have not followed it), so feel
free to ignore it for this discussion or reopen a new discussion...

Regards
Klaus

-----Ursprüngliche Nachricht-----
Von: emacs-devel-bounces+klaus.berndl=sdm.de@gnu.org [mailto:emacs-devel-bounces+klaus.berndl=sdm.de@gnu.org] Im Auftrag von Lennart Borgman
Gesendet: Freitag, 24. Juli 2009 16:21
An: martin rudalics
Cc: Thomas Lord; rms@gnu.org; cyd@stupidchicken.com; joakim@verona.se; emacs-devel@gnu.org; juri@jurta.org; monnier@iro.umontreal.ca; acm@muc.de; drew.adams@oracle.com; Miles Bader
Betreff: Re: Infrastructural complexity.

On Fri, Jul 24, 2009 at 2:10 PM, martin rudalics<rudalics@gmx.at> wrote:
>> As an example consider ECBs windows. There is currently a command in 
>> ECB to hide/show them today. That could be implemented by 
>> hiding/showing a window group.
>
> ECB does this by saving a window configuration, deleting the 
> respective windows, and resurrecting the saved configuration when the 
> user wants the windows to show up again.  Resurrection occurs 
> procedurally, that is by recursively splitting the root window of a frame.


Yes, maybe that is the best way, I am not sure.


> There's no problem doing that the way sketched above.  I'm skeptical 
> about hiding windows by giving them zero height or width, though.


I did not mean giving the zero height ot width. That would be confusing. I meant visibility as a new property.


> My code can split any root window (or any group root window) and clone 
> any saved window group into any of the two emanating halves.  And it 
> does not need to split windows to accomplish that.


That sounds very good. To throw away that part of my code in winsav.el I would need three more things:

- Rotate
- Transpose

and

> The
> additional frame resizing code when a window group that spans an 
> entire side of that frame is removed would have to be written but that 
> seems fairly straightforward.

- Resizing.

Actually the reszing code when putting back a window tree in winsav was one of the most frustrating pieces of code I have written because it had to fight what the C code was doing. I think the resizing code is one of those pieces that should be written in C. It should be much more simple there (the logic I mean ...).