From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Windows' "split status" Date: Tue, 15 Nov 2011 08:30:22 -0500 Message-ID: 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 X-Trace: dough.gmane.org 1321363857 16567 80.91.229.12 (15 Nov 2011 13:30:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 15 Nov 2011 13:30:57 +0000 (UTC) Cc: martin rudalics , emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 15 14:30:53 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 1RQJ6C-0002wf-QY for ged-emacs-devel@m.gmane.org; Tue, 15 Nov 2011 14:30:52 +0100 Original-Received: from localhost ([::1]:53222 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQJ6C-0003EV-BD for ged-emacs-devel@m.gmane.org; Tue, 15 Nov 2011 08:30:52 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:35411) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQJ69-0003EP-M8 for emacs-devel@gnu.org; Tue, 15 Nov 2011 08:30:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQJ68-0008Vo-MZ for emacs-devel@gnu.org; Tue, 15 Nov 2011 08:30:49 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:15075 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQJ62-0008Ux-40; Tue, 15 Nov 2011 08:30:42 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADppwk5MCqs//2dsb2JhbABEqWyBBoFyAQEEAVYjBQsLDiYSFBgNJIgVuVmKEQSIE5lvhEg X-IronPort-AV: E=Sophos;i="4.69,515,1315195200"; d="scan'208";a="148021255" Original-Received: from 76-10-171-63.dsl.teksavvy.com (HELO pastel.home) ([76.10.171.63]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 15 Nov 2011 08:30:22 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 4EB395936A; Tue, 15 Nov 2011 08:30:22 -0500 (EST) In-Reply-To: <871ut9n2rr.fsf@gnu.org> (Chong Yidong's message of "Tue, 15 Nov 2011 17:39:04 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.183 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:146039 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. A > non-nil `window-nest' only means that a parent window can have only two > children. But I think this result is just a consequence of the implementation rather than actual intention. My impression is that window-nest is trying to solve a problem which can't be solved with a user-config: it's trying to provide some kind of way for elisp packages to use parent windows as a form of "very lightweight sub-frame", without touching much of their code (e.g. without making their code use parent windows explicitly). IIUC the use of window-nest for that purpose only works if the application limits itself to using 2 windows within that "sub-frame", so it's not ideal. > 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. But I think it goes even further away from the actual intention and need of (elisp) users. I can't think of any case where you'd want to set this to a value greater than 2, for example. Stefan