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: moving window handling into lisp Date: Thu, 13 Aug 2009 15:56:27 +0200 Message-ID: <4A841B8B.8040107@gmx.at> References: <4A82C49A.4000209@gmx.at> <4A82F64B.2030606@gmx.at> <4A83E300.5000104@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1250175393 14011 80.91.229.12 (13 Aug 2009 14:56:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Aug 2009 14:56:33 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 13 16:56:26 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 1Mbbj3-0002l0-9m for ged-emacs-devel@m.gmane.org; Thu, 13 Aug 2009 16:56:25 +0200 Original-Received: from localhost ([127.0.0.1]:55778 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mbbj1-0003C9-FX for ged-emacs-devel@m.gmane.org; Thu, 13 Aug 2009 10:56:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MbanL-0003Y2-H8 for emacs-devel@gnu.org; Thu, 13 Aug 2009 09:56:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MbanF-0003Uu-2Y for emacs-devel@gnu.org; Thu, 13 Aug 2009 09:56:42 -0400 Original-Received: from [199.232.76.173] (port=39317 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbanE-0003Un-Rd for emacs-devel@gnu.org; Thu, 13 Aug 2009 09:56:36 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:42649) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MbanE-0004B1-7e for emacs-devel@gnu.org; Thu, 13 Aug 2009 09:56:36 -0400 Original-Received: (qmail invoked by alias); 13 Aug 2009 13:56:29 -0000 Original-Received: from 62-47-61-116.adsl.highway.telekom.at (EHLO [62.47.61.116]) [62.47.61.116] by mail.gmx.net (mp049) with SMTP; 13 Aug 2009 15:56:29 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+AYidrkC6ATpsYryxlEgfxTN1EffYlSbFnZtSFTd hJKCIvxdsqKu19 User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.66 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:114177 Archived-At: > This one is easier to play with. [...] >>> Here is the walking down part too. You have to tell me what you are missing. When I try to evaluate that I get Window Root-1 is too small, min=9, but can be max=7 Anyway, I do hope to understand what you mean. When "going up" you calculate minimum and maximum sizes and when "going down" you distribute the frame size recursively among its children according to some "strategy". When the minimum and maximum sizes can't be applied you give up before going down. The problem I see is with the "strategy" that sets the desired sizes. With 'eq-sizes you calculate them on the fly when you "walk down". Unfortunately, this won't help when you just want to enlarge one individual leaf window. In that case we usually resize one adjacent window and leave the other windows alone. You'd probably first set the min/max values of the window you want to enlarge to the desired value, relax the min/max values of an adjacent sibling and leave all other min/max values at the current sizes. If this works out you're done. Otherwise, you'd have to relax min/max values for additional windows and see whether you succeed. You'd probably start doing that process "inside out" by selecting siblings of the window you want to enlarge, siblings of their parent and so on. That's what I meant with backtracking. The complexity of that process is, in the worst case, proportional to the number of possible Emacs tilings of a frame into the windows you have. Obviously, we don't expect the worst case to happen. But we'd probably need some reasonable divide-and-conquer strategy to make sure to always get a good result. Finding such a strategy is the hard part. I suppose your approach would handle the case where you simply want to resize the containing frame. Just calculate the min/max values and look whether the desired window sizes fit into that. After that, adjust the windows arbitrarily with one line/column more or less. But with frame-resizing the hard case is just that we need some heuristics when windows don't fit due to their hard min-weight/-height, fixed-size requirements. martin