Re: Windows' "split status"

[martin rudalics <rudalics@gmx.at>]

 >>> 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