Re: Windows' "split status"

[martin rudalics]

>>> But I think this result is just a consequence of the implementation
>>> rather than actual intention.  My impression is that window-nest is
>>> trying to solve a problem which can't be solved with a user-config: it's
>>> trying to provide some kind of way for elisp packages to use parent
>>> windows as a form of "very lightweight sub-frame", without touching much
>>> of their code (e.g. without making their code use parent windows
>>> explicitly).
>>> IIUC the use of window-nest for that purpose only works if the
>>> application limits itself to using 2 windows within that "sub-frame",
>
>> What makes you think that?
>
> Are you saying that my description of the intention behind window-nest
> is wrong?  Or are you only saying that the "at most 2" limitation is not
> really true. while everything else is right?

When using side windows there must be exactly one major non-side window
containing all other non-side windows.  That window can be considered a
"very lightweight sub-frame".  But the number of subwindows of that
window is not limited in any sense.

> I don't actually know what was the intention behind window-nest, so
> confirmation would be welcome.

Your characterization above is OK.  Just that there's no limitation.

>> You can let-bind `window-nest' to t around a
>> split and get an extra parent around the resulting two windows.  After
>> that you can split those windows any which way you want and can get an
>> arbitrary number of windows within a "sub-frame".  The manual explicitly
>> uses the term "always" in the sentence
>
> That sounds like a rather round-about way to do things (because you have
> let-bind the var around some parts of he code, but not all): wouldn't it
> be easier to start with "create a parent window" (which would start
> containing only the selected window) an then proceed to split it the
> usual way.  That would save you from using let-binding.

There are two problems with this:

(1) I invariantly disallow matryoshka windows, so each internal window
    must have at least two children.  Lifting this invariant might have
    tricky consequences.

(2) When deleting a window makes a parent recombinable with its
    siblings, I must be able to suppress that recombination - otherwise
    the "sub-frame" mechanism will break.

>> `window-nest' is aimed at providing a safe low-level mechanism to
>> construct and preserve parent windows.  Everything else can be easily
>> built in Elisp on top of that, like atomic or side windows.
>
> If it's a low-level mechanism, why is it a defcustom, then?

It's a defcustom because earlier it was just a special value of a
precursor of an option now called `window-combination-resize'.  If you
think it's a bad idea, I can always turn it into a plain variable like
`display-buffer-mark-dedicated'.  OTOH, having it always non-nil makes
the behavior of window deletions more predictable as explained in the
manual.

> If it's aimed at "construct and preserve", why is it a variable, rather
> than a function?

It's a variable _and_ a slot in the window structure and it's used like
`display-buffer-mark-dedicated': Usually for one single call but there's
no harm if someone wants all windows be dedicated or all parent windows
have only two children.

martin