[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Windows' "split status"
Re: Windows' "split status"
Tue, 10 Jan 2012 17:26:35 +0100
>>> 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
>>> 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
(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
> 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.