From: martin rudalics <rudalics@gmx.at>
To: Chong Yidong <cyd@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Windows' "split status"
Date: Tue, 15 Nov 2011 16:15:26 +0100 [thread overview]
Message-ID: <4EC2820E.7010401@gmx.at> (raw)
In-Reply-To: <871ut9n2rr.fsf@gnu.org>
> 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
next prev parent reply other threads:[~2011-11-15 15:15 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-11 15:37 Windows' "split status" Chong Yidong
2011-11-11 18:37 ` martin rudalics
2011-11-12 0:36 ` Chong Yidong
2011-11-12 10:01 ` martin rudalics
2011-11-13 3:23 ` Chong Yidong
2011-11-13 10:49 ` martin rudalics
2011-11-13 16:10 ` Chong Yidong
2011-11-13 17:17 ` martin rudalics
2011-11-15 5:20 ` Chong Yidong
2011-11-15 7:25 ` martin rudalics
2011-11-15 9:39 ` Chong Yidong
2011-11-15 13:30 ` Stefan Monnier
2011-11-15 15:15 ` martin rudalics
2011-11-15 16:24 ` monnier
2012-01-10 16:26 ` martin rudalics
2011-11-23 12:36 ` Nix
2011-11-23 14:15 ` martin rudalics
2011-11-23 17:38 ` Eli Zaretskii
2011-11-23 19:21 ` martin rudalics
2011-11-23 20:14 ` Eli Zaretskii
2011-11-24 10:00 ` martin rudalics
2011-11-24 11:27 ` Eli Zaretskii
2011-11-25 10:24 ` martin rudalics
2011-11-25 11:37 ` Eli Zaretskii
2011-11-25 13:55 ` martin rudalics
2011-11-25 12:00 ` Nix
2011-11-25 12:07 ` Eli Zaretskii
2011-11-25 12:14 ` Nix
2011-11-25 13:55 ` martin rudalics
2011-11-25 13:54 ` martin rudalics
2011-11-15 15:15 ` martin rudalics [this message]
2011-11-15 18:37 ` Juri Linkov
2011-11-16 5:08 ` Chong Yidong
2011-11-16 10:11 ` martin rudalics
2011-11-16 13:34 ` Stefan Monnier
2011-11-16 17:01 ` Juri Linkov
2011-11-17 10:34 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EC2820E.7010401@gmx.at \
--to=rudalics@gmx.at \
--cc=cyd@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.