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: Wed, 12 Aug 2009 19:05:15 +0200 Message-ID: <4A82F64B.2030606@gmx.at> References: <4A7010D7.3050305@gmx.at> <4A81374E.9050401@gmx.at> <4A8283EF.5080007@gmx.at> <4A82C49A.4000209@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 1250098060 14774 80.91.229.12 (12 Aug 2009 17:27:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Aug 2009 17:27:40 +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 Wed Aug 12 19:27:32 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 1MbHbo-0003ID-26 for ged-emacs-devel@m.gmane.org; Wed, 12 Aug 2009 19:27:32 +0200 Original-Received: from localhost ([127.0.0.1]:38039 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbHbl-0005Gx-OJ for ged-emacs-devel@m.gmane.org; Wed, 12 Aug 2009 13:27:29 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MbHGR-0004rJ-7N for emacs-devel@gnu.org; Wed, 12 Aug 2009 13:05:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MbHGL-0004o6-GM for emacs-devel@gnu.org; Wed, 12 Aug 2009 13:05:25 -0400 Original-Received: from [199.232.76.173] (port=56017 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbHGL-0004nz-7B for emacs-devel@gnu.org; Wed, 12 Aug 2009 13:05:21 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:41849) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MbHGK-0002Ui-Bz for emacs-devel@gnu.org; Wed, 12 Aug 2009 13:05:20 -0400 Original-Received: (qmail invoked by alias); 12 Aug 2009 17:05:18 -0000 Original-Received: from 62-47-58-24.adsl.highway.telekom.at (EHLO [62.47.58.24]) [62.47.58.24] by mail.gmx.net (mp071) with SMTP; 12 Aug 2009 19:05:18 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+TaiRyBZWTxiijSlSKPsbRmP4ML/xagV+Znbfaid JatGwJhQA6PjSd User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 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:114148 Archived-At: > I think the problems in the currently used logic may show up like > that, yes. But I am sure you know much more about that. I suppose it can't loop currently. Stefan's window balancing code can loop so he put an upper bound on how often that loop can get executed. > I do not think that fixed size windows is any problem in the algorithm > I gave. You just use that size both when walking up and collecting > (minimal) sizes and when walking down to compute sizes to apply. Maybe. I still don't know whether you have an algorithm in the first place. The recipe you gave lacks two details: (1) How to "collect" the sizes, and (2) how to "apply" them as they could be. > There is so to say no way to get too small windows when computing > sizes to apply, but you can of course find that there is not enough > space if the "sum" of the minimum sizes is too large. But you will > easily see that since on each level when you are going down you know > how much space each sublevel as a mininum needs. With fixed-size windows you have a minimum and a maximum. Surprisingly, fixed-size windows are used in practice as a recent bug report confirms. martin