From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: Windows' "split status" Date: Mon, 14 Nov 2011 00:10:49 +0800 Message-ID: <87obwgatpy.fsf@gnu.org> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1321200666 27302 80.91.229.12 (13 Nov 2011 16:11:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 13 Nov 2011 16:11:06 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 13 17:11:03 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 1RPce6-0000Zu-Py for ged-emacs-devel@m.gmane.org; Sun, 13 Nov 2011 17:11:02 +0100 Original-Received: from localhost ([::1]:45232 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPce6-0001tQ-6f for ged-emacs-devel@m.gmane.org; Sun, 13 Nov 2011 11:11:02 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:57842) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPce3-0001t1-PG for emacs-devel@gnu.org; Sun, 13 Nov 2011 11:11:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RPce2-0003um-Ng for emacs-devel@gnu.org; Sun, 13 Nov 2011 11:10:59 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:41430) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPce2-0003ui-Kx for emacs-devel@gnu.org; Sun, 13 Nov 2011 11:10:58 -0500 Original-Received: from bb116-14-110-22.singnet.com.sg ([116.14.110.22]:60339 helo=furball) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1RPce1-0002ql-Tz; Sun, 13 Nov 2011 11:10:58 -0500 In-Reply-To: <4EBFA0AF.7000608@gmx.at> (martin rudalics's message of "Sun, 13 Nov 2011 11:49:19 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 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:146030 Archived-At: martin rudalics writes: >> What about the nest status? Is there any reason that needs to stick >> around? > > To avoid that recombine_windows removes a parent window that glues > windows together. That's needed for implementing atomic and side > windows which then would work only with `window-nest' permanently t. OK, I see. How about a variation on this scheme: introduce a `max-children' window parameter which, if non-nil, determines the maximum number of children that a window can have (relevant only for internal windows). For atomic and side windows, this window parameter would be explicitly set to 2. When the window parameter is nil or absent, the actual value would be determined by a user option `window-max-children'. That would make the behavior more explicit, I think.