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 20:07:58 +0200 Message-ID: <4A84567E.4080602@gmx.at> References: <4A82F64B.2030606@gmx.at> <4A83E300.5000104@gmx.at> <4A841B8B.8040107@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 1250186909 19844 80.91.229.12 (13 Aug 2009 18:08:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Aug 2009 18:08:29 +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 20:08:21 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 1Mbeim-0001hi-An for ged-emacs-devel@m.gmane.org; Thu, 13 Aug 2009 20:08:16 +0200 Original-Received: from localhost ([127.0.0.1]:59504 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mbeil-0007gE-S5 for ged-emacs-devel@m.gmane.org; Thu, 13 Aug 2009 14:08:15 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mbeih-0007eE-Eu for emacs-devel@gnu.org; Thu, 13 Aug 2009 14:08:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mbeid-0007XD-TK for emacs-devel@gnu.org; Thu, 13 Aug 2009 14:08:11 -0400 Original-Received: from [199.232.76.173] (port=43437 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mbeid-0007X9-Qp for emacs-devel@gnu.org; Thu, 13 Aug 2009 14:08:07 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:46459) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1Mbeid-0005N7-9K for emacs-devel@gnu.org; Thu, 13 Aug 2009 14:08:07 -0400 Original-Received: (qmail invoked by alias); 13 Aug 2009 18:08:05 -0000 Original-Received: from 62-47-56-63.adsl.highway.telekom.at (EHLO [62.47.56.63]) [62.47.56.63] by mail.gmx.net (mp070) with SMTP; 13 Aug 2009 20:08:05 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18PZTlJ6P8PReBN8l7dece0jciXrsqDIcAXeaf/Ic E3ANa+11g3VrTX User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.68 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:114194 Archived-At: >> 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 am not sure why you want to do something like the above. However you > introduce a new element here: relaxing of the requirements. Not only - in the first step I would make them stronger. > Do you really want to do that? Or did I misunderstand you? When I change the size of a particular window on one end of my frame I don't want Emacs to change the sizes of windows at the other end. Changes should be "as local as possible". For example, when I drag a modeline I usually do not expect the sizes of windows not adjacent to that modeline change unless Emacs has no other choice. > More seriously: if you are changing the rules, then please tell what > rules you want to use see we can see if the problem is solveable with > your new rules. What rules? Please tell me _how_ your algorithm would handle a single `enlarge-window' command. Which other windows would change in which order? How would new window sizes relate to the old ones? martin