[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Windows' "split status"
From: |
martin rudalics |
Subject: |
Re: Windows' "split status" |
Date: |
Tue, 15 Nov 2011 16:15:26 +0100 |
User-agent: |
Thunderbird 2.0.0.21 (Windows/20090302) |
> 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
- Re: Windows' "split status", (continued)
- Re: Windows' "split status", martin rudalics, 2011/11/24
- Re: Windows' "split status", Eli Zaretskii, 2011/11/24
- Re: Windows' "split status", martin rudalics, 2011/11/25
- Re: Windows' "split status", Eli Zaretskii, 2011/11/25
- Re: Windows' "split status", martin rudalics, 2011/11/25
- Re: Windows' "split status", Nix, 2011/11/25
- Re: Windows' "split status", Eli Zaretskii, 2011/11/25
- Re: Windows' "split status", Nix, 2011/11/25
- Re: Windows' "split status", martin rudalics, 2011/11/25
- Re: Windows' "split status", martin rudalics, 2011/11/25
- Re: Windows' "split status",
martin rudalics <=
- Re: Windows' "split status", Juri Linkov, 2011/11/15
- Re: Windows' "split status", Chong Yidong, 2011/11/16
- Re: Windows' "split status", martin rudalics, 2011/11/16
- Re: Windows' "split status", Stefan Monnier, 2011/11/16
- Re: Windows' "split status", Juri Linkov, 2011/11/16
- Re: Windows' "split status", martin rudalics, 2011/11/17