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: Mon, 27 Jul 2009 17:28:46 +0200 Message-ID: References: <4A6DAD94.8040006@gmx.at> <4A6DAF71.6070002@gmx.at> <4A6DBB3A.90001@gmx.at> <4A6DC1A1.2000208@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 1248713066 31456 80.91.229.12 (27 Jul 2009 16:44:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2009 16:44:26 +0000 (UTC) Cc: Miles Bader , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 27 18:44: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 1MVTJ4-00028o-RH for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2009 18:44:11 +0200 Original-Received: from localhost ([127.0.0.1]:34493 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVTJ4-0003uy-4X for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2009 12:44:10 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MVS8F-00059o-52 for emacs-devel@gnu.org; Mon, 27 Jul 2009 11:28:55 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MVS89-00058h-V4 for emacs-devel@gnu.org; Mon, 27 Jul 2009 11:28:54 -0400 Original-Received: from [199.232.76.173] (port=50828 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVS89-00058e-OX for emacs-devel@gnu.org; Mon, 27 Jul 2009 11:28:49 -0400 Original-Received: from an-out-0708.google.com ([209.85.132.248]:12251) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MVS87-0008EX-EM; Mon, 27 Jul 2009 11:28:47 -0400 Original-Received: by an-out-0708.google.com with SMTP id b6so2843366ana.21 for ; Mon, 27 Jul 2009 08:28:46 -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=GInu+shaD8oDkczqjVPnLH76WOwqkeys+MrAMxxoJTg=; b=I66zHEzgcJZlwxIW1qVkC5B9lUxEPKGcU+7nn7jN7h7Oneg1QWMPKrkju0MmAWHUEQ cZfKe4sbWMKgd+0Lhq7hulgktyUGP23RpH5+4yi3Ttdi+fAZpneACQypzqMXhSJhQF35 /TVHBGFnb6eaHrPqCdBZkclHe6zbMzuUorJac= 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=Dy9Ji3om4e9mUGnuMWVnjaZ4ZlcHv5Yhfgizd1YrIe9w2DhEc7wZATBmdq7nVsFOFz ImpSzdSTNNH2DXEVNfCSVKiNfLggZ+WUEjm4JjnLrGcBTi9K5bNg9CeHo7JbC0sp4JaW tMgqA/WaQg5Gm2mDk39UlJ/Wx2lCoWNO9WP78= Original-Received: by 10.100.4.9 with SMTP id 9mr8409180and.147.1248708526879; Mon, 27 Jul 2009 08:28:46 -0700 (PDT) In-Reply-To: <4A6DC1A1.2000208@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:113225 Archived-At: On Mon, Jul 27, 2009 at 5:02 PM, martin rudalics wrote: >>> I suppose we agree that it's much simpler when we can set the window >>> sizes directly (and apply any frame resizing afterwards). >> >> Hm, maybe ... ;-) >> >> I do not understand how you mean. But yes, if the sizes can be kept >> (or interpreted) as relative sizes when doing frame resizing. > > I mean that you first have to build the new window tree with the stored > sizes. =C2=A0If the size of the target frame (or window) differs from tha= t of > the source frame (window) you have to resize the windows in the target > (a process which is certainly not guaranteed to keep relative sizes and, > in the worst case, may even delete windows). What I mean is that maybe you have more freedom there when you do this internally. Can't you for example calculate the sizes going down the tree before actually applying them to the windows? Can't you this way calculate all the sizes before applying them? You may then of course have to store them node by node by node, but there will be no surprises when you apply them, or?