From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Windows' "split status" Date: Tue, 15 Nov 2011 16:15:26 +0100 Message-ID: <4EC2820E.7010401@gmx.at> References: <87vcqqoekt.fsf@gnu.org> <4EBD6B63.4050607@gmx.at> <87vcqq6utg.fsf@gnu.org> <4EBE4414.10009@gmx.at> <87d3cwr9hc.fsf@gnu.org> <4EBFA0AF.7000608@gmx.at> <87obwgatpy.fsf@gnu.org> <4EBFFBA5.1000309@gmx.at> <87hb26gdx8.fsf@gnu.org> <4EC213EA.4080304@gmx.at> <871ut9n2rr.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1321370161 338 80.91.229.12 (15 Nov 2011 15:16:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 15 Nov 2011 15:16:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 15 16:15:55 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RQKjm-0004lG-Jp for ged-emacs-devel@m.gmane.org; Tue, 15 Nov 2011 16:15:50 +0100 Original-Received: from localhost ([::1]:58898 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQKjl-0006aI-Oe for ged-emacs-devel@m.gmane.org; Tue, 15 Nov 2011 10:15:49 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:34661) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQKjf-0006ZU-HV for emacs-devel@gnu.org; Tue, 15 Nov 2011 10:15:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQKjZ-0000d9-FQ for emacs-devel@gnu.org; Tue, 15 Nov 2011 10:15:43 -0500 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:57502) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1RQKjZ-0000cs-2e for emacs-devel@gnu.org; Tue, 15 Nov 2011 10:15:37 -0500 Original-Received: (qmail invoked by alias); 15 Nov 2011 15:15:35 -0000 Original-Received: from 62-47-37-59.adsl.highway.telekom.at (EHLO [62.47.37.59]) [62.47.37.59] by mail.gmx.net (mp004) with SMTP; 15 Nov 2011 16:15:35 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19Oz+ETIgZOM0yer9wuWQmuy0/ro8+OUD+NY7Z4S3 Qz3Y/mG50vrwm/ User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <871ut9n2rr.fsf@gnu.org> X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 213.165.64.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:146040 Archived-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