Re: Window configurations

[martin rudalics]

> I remember that differently.  With ECB you can really choose from layouts
> visually and even create new ones with a sort of interactive layout editor.
> It is true that it stored the layouts as procedural sequences internally,
> but that is just an implementation detail.

I was talking about practical issues, i.e., implementation.

> Aside from that it is really trivial to specify any reasonably complex
> layouts as simple lisp structure, with sizes in percent, similar to say
> framesets in html:
>
> (setq my-layout '(

And we'd get this structure from `window-tree', I suppose?  Things like
that have been proposed and written a number of times already.

> That simple thing would be a pretty detailed layout already suited for
> almost all purposes (except GUD perhaps).  More precisely, a layout
> _configuration_, which means that the elements (windows) are shown only
> when needed.
>
> Now you'd have a function that processes the tree to remove the unshown
> components, resizes the remaining components proportionally and then put
> it on screen in one go using good old split-window and then shows the
> buffers

That's what XEmacs does IIUC ...

> on top of each window's buffer stack.

... just that it has no such stack.

> For that of course you need a second set of preferences, that is what
> buffer show in what pane:  For example,  *messages*, *compilation*,
> *completion*, etc.  can be assigned to "tool-window", *speedbar* to
> sidebar-1, *help* on "top-1", files and such to "edit-area", and so on ...

That's what ECB's layouts are supposed to accomplish.  But I still don't
know how we want to use a window's buffer stack.  It's probably trivial
when the only operation popping the stack also kills that buffer.
However, if the buffer remains alive where put it on the stack?  The
only reasonable answer is burying it.  But usually that buffer is the
one a user most likely wants to see first when unshowing another buffer
in that window.

martin