Re: Windows' "split status"

[martin rudalics <rudalics@gmx.at>]

 > My problem with `window-nest' is that the term is misleading: windows
 > can still be "nested" even when `window-nest' is nil, in the sense that
 > groups of live windows are nested within internal parent windows.

Agreed.

 > A non-nil `window-nest' only means that a parent window can have only two
 > children.

Note that "nesting" means two things: To make a parent window when
splitting "in the same direction" and to makes sure that that parent
window is persistent.  Also, nesting can be done in two ways: Either via
the option `window-nest' or via `set-window-nest'.  If you use the
option, you get a two windows nesting right after a split.  If you then
split one of these windows with window-nest nil, you get a nest with
three windows.  With `set-window-nest' you can produce a nest of three
or more windows "a posteriori", that is, a long time after they have
been split off.

 > That's why I think it's better to replace the "window nest status"
 > concept with something like "the number of allowed children", which is
 > more direct.  Then there's no reason to limit to a binary choice between
 > having two children and having unlimited children; we might as well
 > specify the number of children as an arbitrary integer > 1.

Yes.  But I'm afraid of the consequences of this.  In particular if the
variable gets let-bound in between.

 > An alternative term might be window-combination-max-size.

It would be a better name.  Can't you think of a similar term which
doesn't imply a numerical value?

 > I don't care so much about the issue of whether to implement this with a
 > window parameter rather than a special slot.  The former seems
 > conceptually cleaner, but the latter is fine if you think it's
 > technically simpler.

I usually adhered to the following principle: Whatever can be handled on
the Elisp level should be done via parameters.  Slots are used wherever
C code is involved.  `window-splits' was an exception because that
option was previously implemented as a special value of `window-nest'.
The buffer history slots (prev_buffers, next_buffers) are an exception
because they are updated from Fset_window_buffer and initially I was a
bit afraid that messing around with these lists could lead to
unpredictable behavior.  Now I'm quite positive that implementing them
via parameters would be sufficiently safe.

martin