From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: moving window handling into lisp Date: Thu, 13 Aug 2009 13:00:26 -0400 Message-ID: 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=us-ascii X-Trace: ger.gmane.org 1250182851 6817 80.91.229.12 (13 Aug 2009 17:00:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Aug 2009 17:00:51 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 13 19:00:43 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 1MbdfN-0005rR-N9 for ged-emacs-devel@m.gmane.org; Thu, 13 Aug 2009 19:00:42 +0200 Original-Received: from localhost ([127.0.0.1]:57481 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbdfN-00046s-Bz for ged-emacs-devel@m.gmane.org; Thu, 13 Aug 2009 13:00:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MbdfG-00042E-Rf for emacs-devel@gnu.org; Thu, 13 Aug 2009 13:00:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MbdfC-0003pr-JC for emacs-devel@gnu.org; Thu, 13 Aug 2009 13:00:34 -0400 Original-Received: from [199.232.76.173] (port=60329 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbdfC-0003pU-D8 for emacs-devel@gnu.org; Thu, 13 Aug 2009 13:00:30 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:60204) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MbdfB-0008Qp-JT for emacs-devel@gnu.org; Thu, 13 Aug 2009 13:00:30 -0400 Original-Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n7DH0Qmh032762; Thu, 13 Aug 2009 13:00:26 -0400 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 5B3CE9015C; Thu, 13 Aug 2009 13:00:26 -0400 (EDT) In-Reply-To: <4A83E2ED.2090805@gmx.at> (martin rudalics's message of "Thu, 13 Aug 2009 11:54:53 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3340=0 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:114189 Archived-At: >>> Wasn't that something you wanted to avoid? >> No. I did mention that its use to resurrect a deleted window should be >> avoided because it may not work any more at some point in the future. >> But we're here only talking about resizing windows, no deletion. > 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. > 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. > 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. > 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. > 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. >>> 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. >>> An application that can't get a window of the appropriate size might >>> prefer to use a new frame and leave the original configuration >>> unchanged. Should it do that by saving the window configuration and >>> restoring it provided the amount returned by `window-resize' doesn't >>> fit its needs? >> Yes, it could. > 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. Or we could use another algorithm which first figures out what the end tree should look like and then applies the changes, ... Stefan