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:09:38 +0200 Message-ID: <4A8456E2.9020400@gmx.at> References: <4A6DAD94.8040006@gmx.at> <4A6DAF71.6070002@gmx.at> <4A6DBB3A.90001@gmx.at> <4A6DC1A1.2000208@gmx.at> <4A6DDB61.8090403@gmx.at> <4A6EAB02.6080701@gmx.at> <4A7010D7.3050305@gmx.at> <4A81374E.9050401@gmx.at> <4A8283D8.6070208@gmx.at> <4A83E2ED.2090805@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1250187026 20221 80.91.229.12 (13 Aug 2009 18:10:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Aug 2009 18:10:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 13 20:10:19 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 1Mbekk-0002aP-5K for ged-emacs-devel@m.gmane.org; Thu, 13 Aug 2009 20:10:18 +0200 Original-Received: from localhost ([127.0.0.1]:58076 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mbekj-0001uD-Eq for ged-emacs-devel@m.gmane.org; Thu, 13 Aug 2009 14:10:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MbekG-0001RH-HN for emacs-devel@gnu.org; Thu, 13 Aug 2009 14:09:48 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MbekA-0001G2-Up for emacs-devel@gnu.org; Thu, 13 Aug 2009 14:09:47 -0400 Original-Received: from [199.232.76.173] (port=45903 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbekA-0001Fj-P1 for emacs-devel@gnu.org; Thu, 13 Aug 2009 14:09:42 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:58663) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MbekA-0005fR-6g for emacs-devel@gnu.org; Thu, 13 Aug 2009 14:09:42 -0400 Original-Received: (qmail invoked by alias); 13 Aug 2009 18:09:40 -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 (mp039) with SMTP; 13 Aug 2009 20:09:40 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+5w6JSEwe58wGiGXOSztWsghL/psokBAHFMgekCv 199HyATzqVaOcO 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: GNU/Linux 2.6 (newer, 3) 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:114196 Archived-At: >> Deleting windows currently is an inherent part of resizing, > > "currently" is the operative word. I consider it to be a serious flaw > in the current design. We violently agree. In particular the idea of temporarily binding `window-min-height' to some small value and having the next resize operation kill that window strikes me as quite flawed. >> otherwise `window-min-height' and `window-min-width' wouldn't make >> sense. Where and how would you handle these variables? > > They would cause the window resizing to fail. I would only consider > deleting too-small windows when faced with a frame-resize, where failure > would be worse. Agreed. Honestly, do we need these variables? >> That functionality was important enough to blow up the argument list of >> size_window. And that's the function we want to replace, I suppose? > > Could be. I haven't spent enough time looking at the code yet. It's easy to explain: When dragging a modeline, you probably want to shrink/enlarge the bottom-most windows above the modeline and enlarge/shrink the topmost windows below the modeline first. >> I recall a discussion where everyone but me insisted that resizing >> _should_ delete windows that get to small. > > If I did insist on that back then, I was wrong. Luckily, I forgot about > having such a bad idea. Fine (but I don't recall if you participated in that discussion). >> Anyway, we may have to call some such function when resizing a frame and >> that may ultimately require to delete windows. Do you want to delegate >> that to a higher level and re-call our function? > > Yes. There's one small point here: The resizing function might know better which window to delete. WOW the function to pick the candidates for deletion would probably walk the same windows anway. >>>> Also I think that a call with N > 1 failing to resize the window should >>>> be able to result in an abort. >>> It's easy to provide that behavior from outside when needed. >> If window-configuration handling stuff is done within the function you >> have in mind, then there will be two identic configurations we have to >> save at the same time. Why waste that space? > > Maybe we'll decide to provide the feature directly from within, if > performance forces us to. We're sufficiently far from an implementation > that I have no idea why you'd bring up such issues at this point. But it wouldn't harm to consider this from the outset. >> Expensive as explained above. > > Could be. I wouldn't bet on it, tho. If needed, we could even make the > window tree objects a bit more functional, in which case save/restore > a window tree becomes very cheap. Not necessarily cheap. But much, much simpler to code. > Or we could use another algorithm > which first figures out what the end tree should look like and then > applies the changes, ... That's what I had in mind. martin