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: moving window handling into lisp Date: Mon, 27 Jul 2009 14:18:04 -0400 Message-ID: References: <4A6DAD94.8040006@gmx.at> <4A6DAF71.6070002@gmx.at> <4A6DBB3A.90001@gmx.at> <4A6DC1A1.2000208@gmx.at> <4A6DDB61.8090403@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1248718710 20168 80.91.229.12 (27 Jul 2009 18:18:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2009 18:18:30 +0000 (UTC) Cc: emacs-devel@gnu.org, Lennart Borgman , Miles Bader To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 27 20:18:22 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MVUmC-00019h-Jz for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2009 20:18:22 +0200 Original-Received: from localhost ([127.0.0.1]:52558 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVUmB-0003hg-8I for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2009 14:18:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MVUm6-0003hT-Pf for emacs-devel@gnu.org; Mon, 27 Jul 2009 14:18:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MVUm2-0003h9-Ao for emacs-devel@gnu.org; Mon, 27 Jul 2009 14:18:14 -0400 Original-Received: from [199.232.76.173] (port=60248 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVUm2-0003h6-7P for emacs-devel@gnu.org; Mon, 27 Jul 2009 14:18:10 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:37126) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MVUly-00073K-Ms; Mon, 27 Jul 2009 14:18:06 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAL6LbUpFxJuZ/2dsb2JhbACBUdA8hAwFhxU X-IronPort-AV: E=Sophos;i="4.43,277,1246852800"; d="scan'208";a="42305714" Original-Received: from 69-196-155-153.dsl.teksavvy.com (HELO pastel.home) ([69.196.155.153]) by ironport2-out.teksavvy.com with ESMTP; 27 Jul 2009 14:18:04 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 7C26E7F56; Mon, 27 Jul 2009 14:18:04 -0400 (EDT) In-Reply-To: <4A6DDB61.8090403@gmx.at> (martin rudalics's message of "Mon, 27 Jul 2009 18:52:49 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:113242 Archived-At: >> What I mean is that maybe you have more freedom there when you do this >> internally. Can't you for example calculate the sizes going down the >> tree before actually applying them to the windows? Can't you this way >> calculate all the sizes before applying them? You may then of course >> have to store them node by node by node, but there will be no >> surprises when you apply them, or? > I don't know, I would have to code that first. But I wonder why this > didn't occur to you and Stefan when you wrote your window balancing > routines. You both ended up using `adjust-window-trailing-edge' ;-) I know why it didn't occur to me: - I specifically didn't want to use an algorithm like the one that was used in the past (when I wrote the code, which started a long time ago, before adjust-window-trailing-edge') nor like the one that's currently used. I wanted an algorithm that's more declarative: you specify the goal, and the algorithm looks for it without you having to tell it how to do it. - Even if you have the code to compute the desired shape of the tree, it's far from trivial to figure out how to go from the current tree shape to the goal tree shape without bumping into things like window-min-height and window-min-width on intermediate states. Actually most of the code in balance-windows-area was written specifically for that purpose while trying to fix the original balance-windows (which tended to delete windows in some cases for no apparent reason). At some point along the way I figured that I could just as well "compute the goal along the way". Stefan