Re: split-window-preferred-function

[grischka]

From: "martin rudalics":

> IIUC elscreen is useful for switching between existing layouts.  Such
> layouts are obtained by recursively splitting a root window horizontally
> or vertically.  You can record such a layout in volatile memory by
> calling `current-window-configuration' and you can re-create it from
> there via `set-window-configuration'.  But you cannot (easily) define
> and subsequently create such a layout manually.  Hence elscreen seems
> hardly of any help in this context.  Please correct me if I'm wrong.

Actually elscreen has a separate "layout creation" mode (although it
is not as easy to use, and also IMO redundant, it could as well just 
live record user changes made in the "real" frame). 

But yes, you can save everything to disk, anytime.  Means it allows 
to get used to something, body-language wise. 

> I can think of two options:
> 
> 1. Make the underlying window structure accessible in Elisp - via
>     parameters or functions like `window-parent' and `set-window-parent'.
>     This would require careful design of things like `set-window-parent'
>     to avoid introducing incoherent or faulty window layouts via Elisp.
> 
> 2. Write a collection of functions that recursively tile a root window
>     in some well-defined manner according to rules that humans can easily
>     write, read and understand.  Maybe some of these layouts should be
>     depicted in a graphical fashion, for example, in the toolbar (my
>     Thunderbird permits me to choose among three basic tilings).

Option three: Allow zero-width and zero-height windows. 

For example:

+---+-----------+
|   |           |
|   |           |
|   |           |
|   |           |
|   |           |
|   |           | <--
|   |           |
|   |           |
+===+===========+

As you don't see there is a zero-height window at bottom, which 
when "on" spans up to the arrow, but is invisible by default.

Such there is actually no need for the code to *ever* create 
new windows automatically, because the "tree" is already either 
predefined and/or customized. Just the sizes aren't filled in always.

All windows would have some target class-properties, like "file", 
"help", "commandline", so if some buffer needs to be shown, the 
buffer/window-manager (which of I assume emacs has one) can apply 
some logic which buffer to show in what window.

For example:

(window
    :name "bottom-display"
    :content-classes '("*help*" "*output*" ...)
    ...
    :visible 'if-needed

Still the user is allowed to modify the tree anytime of course, 
by split-window or whatever.  Just not the code.  

--- grischka