From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: moving window handling into lisp Date: Thu, 13 Aug 2009 18:43:44 +0200 Message-ID: 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 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1250182039 4187 80.91.229.12 (13 Aug 2009 16:47:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Aug 2009 16:47:19 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 13 18:47:12 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 1MbdSJ-0008Cd-Hy for ged-emacs-devel@m.gmane.org; Thu, 13 Aug 2009 18:47:11 +0200 Original-Received: from localhost ([127.0.0.1]:51907 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbdSJ-0006lA-18 for ged-emacs-devel@m.gmane.org; Thu, 13 Aug 2009 12:47:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MbdP5-00020l-1F for emacs-devel@gnu.org; Thu, 13 Aug 2009 12:43:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MbdP1-0001t6-47 for emacs-devel@gnu.org; Thu, 13 Aug 2009 12:43:50 -0400 Original-Received: from [199.232.76.173] (port=38968 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbdP0-0001sn-KZ for emacs-devel@gnu.org; Thu, 13 Aug 2009 12:43:46 -0400 Original-Received: from mail-yx0-f172.google.com ([209.85.210.172]:44004) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MbdP0-0003NI-54 for emacs-devel@gnu.org; Thu, 13 Aug 2009 12:43:46 -0400 Original-Received: by yxe2 with SMTP id 2so1194087yxe.14 for ; Thu, 13 Aug 2009 09:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GlAMmrgkSOeZbYQRN5MesreTQLcGmTvijqwODUeTMHo=; b=LdIqta+PDcq2ES/EOPLrqRuOznELdpC+bOFMuievCODrjRvGPOxG6Q5OAhLGUmT5BB 2h6CTu+f7AsOJBxi8aGDweH2QfF/RhtZ9JCygVFuZsjv/uJTTzDeIBoyFP8Qt+9ykF0t FZS+gWa+op9K8QR1Sad/kJVCxASQ4YHH+nRbg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=x7nHYfJTsSFiVEXTx77qfYsqC92NDZOZfdr9icbZBMMUUr0vmsFp4082CLxFYZcZBP hZHiejoL3E89ei4pCCu1ZjYLh+/h7J7EllwOlORGLvGRm6N7qgkySbxkke83BVxNg2Ej qxdvyBeuz4JJi0ad8SZUFJ5gUojJ8s/VID4yI= Original-Received: by 10.100.164.20 with SMTP id m20mr532824ane.142.1250181824910; Thu, 13 Aug 2009 09:43:44 -0700 (PDT) In-Reply-To: <4A841B8B.8040107@gmx.at> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:114186 Archived-At: On Thu, Aug 13, 2009 at 3:56 PM, martin rudalics wrote: >> 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=3D9, but can be max=3D7 Yes, that how it should be. You evaluate this file to test. Look at the bottom of the file. > Anyway, I do hope to understand what you mean. =C2=A0When "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". =C2=A0When the minimum and maximum sizes can't be applied you > give up before going down. Yes, you catch the errors going up before you try to apply. > 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. =C2=A0In that case we usually resize one adjacent > window and leave the other windows alone. =C2=A0You'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. =C2=A0If this works out you're done. > > Otherwise, you'd have to relax min/max values for additional windows and > see whether you succeed. =C2=A0You'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. =C2=A0That's what I meant with > backtracking. =C2=A0The 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. =C2=A0Obviously, we don't expect the worst case to happ= en. > But we'd probably need some reasonable divide-and-conquer strategy to > make sure to always get a good result. =C2=A0Finding such a strategy is t= he > 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. Do you really want to do that? Or did I misunderstand you? Of course, chaning the boundaries/requirement can lead to infinite recursion.... ;-) 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. On the other hand, if you do not change the rules, then I can't see why the algorithm I provided can't be used when you enlarge a single window. But maybe you can, so please tell me. > I suppose your approach would handle the case where you simply want to > resize the containing frame. =C2=A0Just calculate the min/max values and = look > whether the desired window sizes fit into that. =C2=A0After that, adjust = the > windows arbitrarily with one line/column more or less. =C2=A0But 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. If they do not fit, they do not fit. So you mean we should have new rules t= hen? Maybe. I am not sure. But if you please tell what rules you are thinking of then I will try to put it into the algorithm (in case you do not do it yourself, of course). I could think of some rules to use, so it is not totally unfamiliar to me. How about a rule like this: - If the windows are too large then allow shrinking them to a system wide default minimum size. Such a rule could easily be added to the algorithm like this: - run a first pass bottom-up. - if it did not fit run a second bottom-up pass with the new rules. > martin >