From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: the window tree, window-combination-limit Date: Thu, 01 Dec 2016 11:09:29 +0100 Message-ID: <583FF6D9.1090904@gmx.at> References: <20822.1480568889@allegro.localdomain> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1480587034 18650 195.159.176.226 (1 Dec 2016 10:10:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Dec 2016 10:10:34 +0000 (UTC) To: Mike Kupfer , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 01 11:10:30 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cCOJx-0004WP-Kn for ged-emacs-devel@m.gmane.org; Thu, 01 Dec 2016 11:10:29 +0100 Original-Received: from localhost ([::1]:55245 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCOK1-0005y3-HV for ged-emacs-devel@m.gmane.org; Thu, 01 Dec 2016 05:10:33 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33856) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCOJQ-0005xm-BY for emacs-devel@gnu.org; Thu, 01 Dec 2016 05:09:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCOJM-0003xm-Ta for emacs-devel@gnu.org; Thu, 01 Dec 2016 05:09:56 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:64767) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cCOJM-0003vx-Jq for emacs-devel@gnu.org; Thu, 01 Dec 2016 05:09:52 -0500 Original-Received: from [192.168.1.100] ([212.95.7.40]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MAgvb-1c0XX13Vql-00BtIv; Thu, 01 Dec 2016 11:09:44 +0100 In-Reply-To: <20822.1480568889@allegro.localdomain> X-Provags-ID: V03:K0:AUoJh1ZUT+dWqSegVNFzIIgTz+SU2ED9rq8XR7PsKqw9M+cou8D 73D1xtJ1aqGfPj9RGmkdyhn35OTv9HeoRLkRc8Shkq0EGWvCYGpgo0y4mISpKsmmC/+0aiA R4D9zprN7s24SVgqT1DYDShjfWSu/xVxaXkmyQraA/VKhCSIl1qBvwHYzsaWEjI7KQDS3W0 pmarHZV3KtwIn2NOemn6w== X-UI-Out-Filterresults: notjunk:1;V01:K0:0lWF0hlw3UM=:lgY+oPMP3WxFR6HQaTtCnU o6FtSHx3jbPlceL85bQX8RpRKYeiSg4I5MQPNHe7i3s/Bq7llFOCvVzpgyZfrGlNQLX9uWETU 4Cgm7BwBiqXtq5ZmHqXzEijuwuLXEXda99EvXpM758BKB+osZkuTQeu5GL/8ALqoLXS/Es0hz sw7cgcYzdhYAV99MEga0EOnoG9C/kziuHF8/Ya+3RMPFFA+gh1cDmYIBZ9yUDqEg9XaNvw88A 2hjr3DhyeTmiCH8nmaGDjS1SZyonSXutGrcRgI2sUTFEe3gr4VYlFgKwjSSaU5cpYhTsA+ULb EAj3rT5Kidmc24jZhNJVPrjOz39pt3uz36JcJQukNPsA0xcpexQB8fL2Hc3TMFi6x/XN1ePsM GDZ1wkcRJu277koIXK4IlwlqeGtBuBJ/DbjUbOUx/RP0LFOILcfI3xpdW82qSHIU48ENTe1JO RxGrPkZQOVwo5HnkZm0CcGLOiLUJ545fzhWeWmTOXgr8pPI7kZk4+QUUsM880CdckP1wrxnpq 9az5H/i3Sx4Hvf6RB1W4ig8cOAVg3NTYXL8eATKKEiCRKefajBhg9RpYkIZ0wZ9Eya8m69hcM y0dNmybMY6SnsjG8RgPoAQ/jt2l0oFEj5GJI2s3I+aF+lbqk9srlCwPWlBsKvLECUvXkYEx58 l/w4h6y8H17IkMF2epjpXawGrr1NIGF/qAX6pdzpFIqW8smi+MpakB137DmccTtoILcHmi7J9 Aag3gQJIbtnRc9OV9F4Z2D1GDu5NfIticgtKUrjwxv5/MXTZ9ojLgEJOawzL2UzBBDpvNEdK X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.15.19 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:209870 Archived-At: > The discussion for bug 25055 mentioned the variable > window-combination-resize. Since I frequently use balance-windows aft= er > splitting or deleting a window, window-combination-resize looked worth= > investigating. With the =E2=80=98window-combination-resize=E2=80=99 approach, Emacs only= operates on the combination affected by a particular split or deletion. Also, a specific operation can override balancing without having to resort to protecting window sizes. =E2=80=98balance-windows=E2=80=99 and =E2=80=98= balance-windows-area=E2=80=99 OTOH operate on all windows and will relentlessly resize all windows that have not been protected. > Its docstring (in 25.1.90) says > > This variable takes no effect if the variable =E2=80=98window-combi= nation-limit=E2=80=99 is > non-nil. > > so I also looked at window-combination-limit. I have a couple questio= ns > as a result. > > The default value for window-combination-limit is 'window-size', which= > is documented as > > =E2=80=98window-size=E2=80=99 means that splitting a window for dis= playing a buffer > makes a new parent window provided =E2=80=98display-buffer=E2=80= =99 is supposed to > explicitly set the window=E2=80=99s size due to the presence of= a > =E2=80=98window-height=E2=80=99 or =E2=80=98window-width=E2=80=99= entry in the alist used by > =E2=80=98display-buffer=E2=80=99. Otherwise, this value is han= dled like nil. > > After several attempts I can parse the first sentence, but I'm having > trouble understanding its significance. Normally, when =E2=80=98window-combination-resize=E2=80=99 resize is non-= nil, you have a frame with two windows above each other and split one of these windows via C-x 2, the emanating three windows all have approximately the same height. An invocation of =E2=80=98display-buffer=E2=80=99, however, migh= t want to give the new window a specific height. For this purpose it has to override the normal impact of =E2=80=98window-combination-resize=E2=80=99 but _onl= y_ for this particular split. "Normal" C-x 2 splits are not affected by the default setting of =E2=80=98window-combination-limit=E2=80=99. I now tried to improve the doc-string of =E2=80=98window-combination-resi= ze=E2=80=99 but am aware that describing this option without describing the behavior in much more detail and examples is fruitless. Suggestions welcome. > More generally, as a user, should I care about the window tree and > parent windows? A web search on > > emacs parent window > > gives me several hits in the Emacs Lisp Reference Manual, but I don't > see anything about the window tree in the Emacs Manual. Can someone > explain the different values for window-combination-limit in terms of > what I would see as a user? =E2=80=98window-combination-limit=E2=80=99 is of minor interest for the u= ser. If it's t, you can be sure that when you delete a window, it's space is always given back to the window from where it was split off (or that window's former ancestor if it has been deleted meanwhile). This makes a difference when that split was made by =E2=80=98split-window=E2=80=99 wit= h the SIDE argument =E2=80=98above=E2=80=99 or =E2=80=98left=E2=80=99. Consider the= following code: (let* ((window-combination-limit nil) (window1 (split-window)) (window2 (split-window window1 nil 'above))) (delete-window window2)) and compare it with (let* ((window-combination-limit t) (window1 (split-window)) (window2 (split-window window1 nil 'above))) (delete-window window2)) Also, if =E2=80=98window-combination-limit=E2=80=99 is nil, it's misused = by a couple of functions like =E2=80=98display-buffer=E2=80=99 to obtain a behavior that= ascertains a specific size for a new window or the creation of a parent window. I'm afraid my explanations are not very illuminating. It's easier to answer specific questions ... martin