From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: monnier@IRO.UMontreal.CA Newsgroups: gmane.emacs.devel Subject: Re: Windows' "split status" Date: Tue, 15 Nov 2011 11:24:01 -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> <4EC2821C.4020400@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1326204330 28240 80.91.229.12 (10 Jan 2012 14:05:30 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 10 Jan 2012 14:05:30 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 10 15:05:25 2012 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 1RkcKK-0002Jn-Ry for ged-emacs-devel@m.gmane.org; Tue, 10 Jan 2012 15:05:25 +0100 Original-Received: from localhost ([::1]:49848 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RkcKK-0007HJ-8C for ged-emacs-devel@m.gmane.org; Tue, 10 Jan 2012 09:05:24 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:33143) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RkcKC-0007HB-RE for emacs-devel@gnu.org; Tue, 10 Jan 2012 09:05:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RkcK7-00026w-2J for emacs-devel@gnu.org; Tue, 10 Jan 2012 09:05:16 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:40165) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RkcK6-00026l-UL; Tue, 10 Jan 2012 09:05:11 -0500 Original-Received: from asado (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id q0AE56xX011140; Tue, 10 Jan 2012 09:05:06 -0500 Original-Received: by asado (Postfix, from userid 20848) id 70BBE5008B; Tue, 15 Nov 2011 11:24:01 -0500 (EST) In-Reply-To: <4EC2821C.4020400@gmx.at> (martin rudalics's message of "Tue, 15 Nov 2011 16:15:40 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 1 X-NAI-Spam-Rules: 2 Rules triggered DATE_IN_PAST_96_XX=1, RV4096=0 X-NAI-Spam-Version: 2.2.0.9309 : core <4096> : streams <718468> : uri <1044183> X-NAI-Spam-Level: * X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.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:147569 Archived-At: >> 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", > What makes you think that? Are you saying that my description of the intention behind window-nest is wrong? Or are you only saying that the "at most 2" limitation is not really true. while everything else is right? I don't actually know what was the intention behind window-nest, so confirmation would be welcome. > You can let-bind `window-nest' to t around a > split and get an extra parent around the resulting two windows. After > that you can split those windows any which way you want and can get an > arbitrary number of windows within a "sub-frame". The manual explicitly > uses the term "always" in the sentence That sounds like a rather round-about way to do things (because you have let-bind the var around some parts of he code, but not all): wouldn't it be easier to start with "create a parent window" (which would start containing only the selected window) an then proceed to split it the usual way. That would save you from using let-binding. > `window-nest' is aimed at providing a safe low-level mechanism to > construct and preserve parent windows. Everything else can be easily > built in Elisp on top of that, like atomic or side windows. If it's a low-level mechanism, why is it a defcustom, then? If it's aimed at "construct and preserve", why is it a variable, rather than a function? Stefan