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: Fri, 14 Aug 2009 13:21:21 +0200 Message-ID: References: <4A841B8B.8040107@gmx.at> <4A84567E.4080602@gmx.at> <4A850FBE.7030402@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 1250248903 9520 80.91.229.12 (14 Aug 2009 11:21:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Aug 2009 11:21:43 +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 Fri Aug 14 13:21:35 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 1Mbuqj-0008OC-Ji for ged-emacs-devel@m.gmane.org; Fri, 14 Aug 2009 13:21:33 +0200 Original-Received: from localhost ([127.0.0.1]:48192 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mbuqi-0007Zb-VB for ged-emacs-devel@m.gmane.org; Fri, 14 Aug 2009 07:21:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mbuqc-0007Vu-Sc for emacs-devel@gnu.org; Fri, 14 Aug 2009 07:21:26 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MbuqY-0007Rr-Dv for emacs-devel@gnu.org; Fri, 14 Aug 2009 07:21:26 -0400 Original-Received: from [199.232.76.173] (port=39314 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbuqY-0007Ri-8t for emacs-devel@gnu.org; Fri, 14 Aug 2009 07:21:22 -0400 Original-Received: from an-out-0708.google.com ([209.85.132.242]:19868) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MbuqX-0005Ca-Us for emacs-devel@gnu.org; Fri, 14 Aug 2009 07:21:22 -0400 Original-Received: by an-out-0708.google.com with SMTP id b6so632989ana.21 for ; Fri, 14 Aug 2009 04:21:21 -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=RIlMgbl72S1mFMH91hdOVBhaQ+fpRjBYloPTlB6FJhM=; b=mUkfgoF9P7IOKnJgcYuvZHpiMf/NskpK4KpTbGV1bQsdjzDwXzdraldoEXX5tccDpf ZGhiHo4bQJm2flSElB65qozk0QJDvB6LDY2q5CkjLf9f9yZEfdwBkNOGp4Um1WmqOy1S JYsRZAkv5D9jj+j+hTPOd8DoQ9jv4jWTY4/eI= 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=lOzEFFIJ9fwNn0cAVdl8N/VfNpcqmJ+N2Py1cY0vTqOdgPc8SOQKys1Uurzi66nBPL Cc1D/hpFeE5wwDCwB8HE3KjGvae15b/awgh83E8C5WgZJnhYJ30YZbmECAVaD7EwTpcS gff1kvCKQ50jikhJRFCmQqq49LJtZ8b0QhQKQ= Original-Received: by 10.100.80.2 with SMTP id d2mr1685814anb.35.1250248881382; Fri, 14 Aug 2009 04:21:21 -0700 (PDT) In-Reply-To: <4A850FBE.7030402@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:114239 Archived-At: On Fri, Aug 14, 2009 at 9:18 AM, martin rudalics wrote: > None, if the adjacent subtree can handle the request. =C2=A0All sorts of > otherwise. =C2=A0That's where the "temporary restrictions" you mention mu= st > be relaxed. Ok. Could you please then summarize what rules you have thought of here? What is it that should be relaxed? What do you want to happen then? What problems do you see for different solutions there? (Not the algorithms, just the rules, please.) >> A very important idea in the algorithm is that it works with all the >> child windows on level at once. You compute all the sizes on that >> level and then you apply them. (So a new function in C for applying >> the changes per sublevel is needed.) >> >> To apply enlarge-window (or any similar command) =C2=A0-- or, VERY >> important, rather what it does --- simply set fix size restrictions on >> that windows size (to the desired size) and other windows (to their >> current sizes) on that level that is not adjecent to the window that >> we try to enlarge. >> >> If this fails then then take away the restrictions on windows >> next-adjecent and try again. Repeat until success or final failure. >> (The order of repetioins is just the lenght of the list, there is no >> recursions, so it is no performance problem.) > > The recursion (or backtracking) is right with the "take away the > restrictions on windows next-adjecent and try again". =C2=A0It doesn't he= lp > if you remove that crucial detail from your algorithm and leave it to > the caller to handle it. Sorry, I must have expressed myself unclear in some way. There is no recursion in my example above, just a simple iteration when taking away the restrictions. One iteration for every sibling window where you take away the restriction. There is no "crucial details" left out. I just did not have time to write an example of enlarge-window and left it to your imagination here. I will try to find some minutes in do write enlarge-window this way, but it would help very much if you tried to summarize your views of the restrictions. (As I already said above.) > Applying the restrictions is trivial. =C2=A0The point is in finding the r= ight > set of restrictions. Yes. But finding a useful set of restrictions can't be done without considering the structure of the code. And that is what I am trying to do. Without that you might get the impression that the problem is np-complete while it is the structure of the current code that perhaps (as I see it) is the problem instead. >> Note: The existing enlarge-window should in this scenario go away and >> a new one should be implemented (probably in elis then) that does the >> above things. The same apply to the other window handling routines >> that does similar things. > > As long as we can't at least emulate the present (poor) behavior ... ;-) Doing it the way I suggest you can slightly change the rules so we can avoid some of the troubles. But to show that we must get into some more concrete exampel I guess. So please (again) tell me some example of rules that you find troublesome. You may have some very good point that I am totally missing. That will show probably show up if we consider some more concrete example and rules. > martin >