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: Wed, 12 Aug 2009 22:32:33 -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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1250130791 28721 80.91.229.12 (13 Aug 2009 02:33:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Aug 2009 02:33:11 +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 04:33:04 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 1MbQ7k-0002lJ-8a for ged-emacs-devel@m.gmane.org; Thu, 13 Aug 2009 04:33:04 +0200 Original-Received: from localhost ([127.0.0.1]:56299 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbQ7h-0006ha-MJ for ged-emacs-devel@m.gmane.org; Wed, 12 Aug 2009 22:33:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MbQ7M-0006KX-AN for emacs-devel@gnu.org; Wed, 12 Aug 2009 22:32:40 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MbQ7H-0006D7-FX for emacs-devel@gnu.org; Wed, 12 Aug 2009 22:32:39 -0400 Original-Received: from [199.232.76.173] (port=46128 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbQ7H-0006Ci-8Y for emacs-devel@gnu.org; Wed, 12 Aug 2009 22:32:35 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:48389) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MbQ7G-0007NH-Py for emacs-devel@gnu.org; Wed, 12 Aug 2009 22:32:35 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAMMXg0pMCoTf/2dsb2JhbACBUtFihBkFhz4 X-IronPort-AV: E=Sophos;i="4.43,371,1246852800"; d="scan'208";a="43443634" Original-Received: from 76-10-132-223.dsl.teksavvy.com (HELO pastel.home) ([76.10.132.223]) by ironport2-out.teksavvy.com with ESMTP; 12 Aug 2009 22:32:13 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id A22297F24; Wed, 12 Aug 2009 22:32:33 -0400 (EDT) In-Reply-To: <4A8283D8.6070208@gmx.at> (martin rudalics's message of "Wed, 12 Aug 2009 10:56:56 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) 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:114163 Archived-At: >> There'd be new low-level functions to resize windows which would work in >> simple and predictable ways, but with the end-state being potentially >> invalid. > And how'd we revert to a valid state? Using `set-window-configuration'? The concept of transaction says that wehn you reach the end, you check that things went right and if they don't you revert to the start state. So yes, obviously it'd internally use something similar to set-window-configuration. > 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. > For modeline dragging we need a function which resizes a window by > moving _one edge_ only (which can be either the leading or the trailing > one). If, in addition, we want to call that function recursively we > must be able to specify _which edge_ it should move, that is, it must be > able to move trailing _and_ leading edges. Yes, that'd probably be a different function from the one I suggested, tho it could/would probably use the one I suggested for part of its work. > Moreover, we probably want > to specify whether the function is allowed to delete windows, resize > windows below `window-min-height' or `window-min-width', or ignore the > value of `window-size-fixed'. At the user-level, it's pretty clear: no function resizing should ever delete a window, resize a window below window-min-height or window-min-width or ignore window-size-fixed. > 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. > 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. >> ... on siblings and/or children. > Including siblings of the window's parent, grandparent, ... I suppose. That is the tricky part of th algorithm, indeed. >> It can't fail and cannot result in an invalid window-tree. > IMO `window-resize' should be written in Elisp while the check whether a > window tree is invalid would reside in C to guarantee that Elisp code > never crashes Emacs. Yes, it's part of my working assumption. Stefan