Re: Window configurations

[grischka <grishka@gmx.de>]

martin rudalics wrote:
>  > In my book configuration is rules and state is result from their application
>  > (together with other conditions).  Conflating the both will just produce a
>  > classical chicken & egg problem.
> 
> If you specify a configuration procedurally you have to supply (1) an
> initial state and (2) a set of actions and the order in which these
> actions are applied.  In the context of window configurations, the state
> resulting after applying (2) to (1) is the "state of all windows" as I
> call it.  Hence the difference is basically only a matter of taste,
> theroretically.

It might be a matter of taste whether you prefer eggs or chicken but
the difference is certainly more than theoretical ;)

>  From a practical point of view things are different: If you want to
> derive (1) and (2) from the state of Emacs at some arbitrary point of
> time you do have to guess a _minimum_ set of actions/rules that
> reproduce the state of windows.  Otherwise, you end up like the
> designers of ECB who record _all_ actions applied by the user and
> "replay" them to produce the desired state.

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.

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 '(
      (div-v
       (30 div-h
           (75 top-window-1)
           (25 top-window-2)
           )
       (55 div-h
           (25 div-v
               (50 sidebar-1)
               (25 sidebar-2)
               (25 sidebar-3)
               )
           (75 edit-area)
           )
       (15 tool-window)
       )))

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 on top of each window's buffer 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 ...

--- grischka