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, 10 Jan 2012 17:26:35 +0100 Message-ID: <4F0C66BB.9000800@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> <4EC2821C.4020400@gmx.at> 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 1326212816 30905 80.91.229.12 (10 Jan 2012 16:26:56 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 10 Jan 2012 16:26:56 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org To: monnier@IRO.UMontreal.CA Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 10 17:26:51 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 1RkeXC-0003sY-7P for ged-emacs-devel@m.gmane.org; Tue, 10 Jan 2012 17:26:50 +0100 Original-Received: from localhost ([::1]:34851 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RkeXB-0003On-HD for ged-emacs-devel@m.gmane.org; Tue, 10 Jan 2012 11:26:49 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:47246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RkeX5-0003NC-Lq for emacs-devel@gnu.org; Tue, 10 Jan 2012 11:26:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RkeX1-0006wO-6F for emacs-devel@gnu.org; Tue, 10 Jan 2012 11:26:43 -0500 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:59593) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1RkeX0-0006vq-Qq for emacs-devel@gnu.org; Tue, 10 Jan 2012 11:26:39 -0500 Original-Received: (qmail invoked by alias); 10 Jan 2012 16:26:37 -0000 Original-Received: from 62-47-50-238.adsl.highway.telekom.at (EHLO [62.47.50.238]) [62.47.50.238] by mail.gmx.net (mp014) with SMTP; 10 Jan 2012 17:26:37 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+EZD0sgJeEUKC/zCks1gVQtg29Ah4ChNLmJZzpQ4 vOiODsVGUWKcnG In-Reply-To: X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:147572 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? When using side windows there must be exactly one major non-side window containing all other non-side windows. That window can be considered a "very lightweight sub-frame". But the number of subwindows of that window is not limited in any sense. > I don't actually know what was the intention behind window-nest, so > confirmation would be welcome. Your characterization above is OK. Just that there's no limitation. >> 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. There are two problems with this: (1) I invariantly disallow matryoshka windows, so each internal window must have at least two children. Lifting this invariant might have tricky consequences. (2) When deleting a window makes a parent recombinable with its siblings, I must be able to suppress that recombination - otherwise the "sub-frame" mechanism will break. >> `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? It's a defcustom because earlier it was just a special value of a precursor of an option now called `window-combination-resize'. If you think it's a bad idea, I can always turn it into a plain variable like `display-buffer-mark-dedicated'. OTOH, having it always non-nil makes the behavior of window deletions more predictable as explained in the manual. > If it's aimed at "construct and preserve", why is it a variable, rather > than a function? It's a variable _and_ a slot in the window structure and it's used like `display-buffer-mark-dedicated': Usually for one single call but there's no harm if someone wants all windows be dedicated or all parent windows have only two children. martin