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: Fri, 14 Aug 2009 09:18:22 +0200 Message-ID: <4A850FBE.7030402@gmx.at> References: <4A83E300.5000104@gmx.at> <4A841B8B.8040107@gmx.at> <4A84567E.4080602@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 1250238099 11186 80.91.229.12 (14 Aug 2009 08:21:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Aug 2009 08:21:39 +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 Fri Aug 14 10:21: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 1Mbs2V-00019s-K5 for ged-emacs-devel@m.gmane.org; Fri, 14 Aug 2009 10:21:31 +0200 Original-Received: from localhost ([127.0.0.1]:42783 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mbs2U-0008VR-OM for ged-emacs-devel@m.gmane.org; Fri, 14 Aug 2009 04:21:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mbrza-0007HD-Hs for emacs-devel@gnu.org; Fri, 14 Aug 2009 04:18:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MbrzW-0007Gp-0T for emacs-devel@gnu.org; Fri, 14 Aug 2009 04:18:30 -0400 Original-Received: from [199.232.76.173] (port=59015 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbrzV-0007Gh-LH for emacs-devel@gnu.org; Fri, 14 Aug 2009 04:18:25 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:47537) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MbrzV-0000qf-2T for emacs-devel@gnu.org; Fri, 14 Aug 2009 04:18:25 -0400 Original-Received: (qmail invoked by alias); 14 Aug 2009 07:18:24 -0000 Original-Received: from 62-47-41-235.adsl.highway.telekom.at (EHLO [62.47.41.235]) [62.47.41.235] by mail.gmx.net (mp064) with SMTP; 14 Aug 2009 09:18:24 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19pp00/n0ppv5wFJd/klo7V2Ff9o1Efu/EZiqOfDk BO4/bJVZKWVUzR 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: 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:114225 Archived-At: > You just have to find the window subtree that is adjecent to the > modeline and apply the algorithm there. (With new temporary > restrictions there. These things must of course be added to the > algorithm, but I can't see any fundamental problem with it.) > > What problems do you see with that? None, if the adjacent subtree can handle the request. All sorts of otherwise. That's where the "temporary restrictions" you mention must be relaxed. > 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) -- 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". It doesn't help if you remove that crucial detail from your algorithm and leave it to the caller to handle it. > Of course I did not implement an easy way to apply the restrictions > right now but that is easily added (except for my clumsiness... ;-). Applying the restrictions is trivial. The point is in finding the right set of restrictions. Compare how modeline dragging is done in Emacs 21 and Emacs 22. The differences show up come because Emacs 22 does not relax the respective restrictions. OTOH relaxing them got us into all sorts of troubles in Emacs 21. > 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 ... martin