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: Mon, 27 Jul 2009 17:02:57 +0200 Message-ID: <4A6DC1A1.2000208@gmx.at> References: <4A6DAD94.8040006@gmx.at> <4A6DAF71.6070002@gmx.at> <4A6DBB3A.90001@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 1248712568 29744 80.91.229.12 (27 Jul 2009 16:36:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2009 16:36:08 +0000 (UTC) Cc: Miles Bader , emacs-devel@gnu.org To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 27 18:36:01 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 1MVTB9-0006qy-2L for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2009 18:35:59 +0200 Original-Received: from localhost ([127.0.0.1]:38141 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVTB8-0006jd-Ep for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2009 12:35:58 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MVRjE-0008Lt-ME for emacs-devel@gnu.org; Mon, 27 Jul 2009 11:03:04 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MVRjA-0008JJ-ME for emacs-devel@gnu.org; Mon, 27 Jul 2009 11:03:04 -0400 Original-Received: from [199.232.76.173] (port=48293 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVRjA-0008J6-Cw for emacs-devel@gnu.org; Mon, 27 Jul 2009 11:03:00 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:58707) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MVRj9-00029b-I1 for emacs-devel@gnu.org; Mon, 27 Jul 2009 11:02:59 -0400 Original-Received: (qmail invoked by alias); 27 Jul 2009 15:02:58 -0000 Original-Received: from 62-47-46-195.adsl.highway.telekom.at (EHLO [62.47.46.195]) [62.47.46.195] by mail.gmx.net (mp070) with SMTP; 27 Jul 2009 17:02:58 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/rfGdwaQfrbNLI6zpRvkOiR7sM8CNQlb4olqX2az rJQF4DpbnYbW87 User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.7 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:113224 Archived-At: >> It's not transparent, that is, it depends on the order how things are >> done. You can set window attributes like `window-size-fixed' only after >> splitting. > > That sounds like a real problem. Can't that be moved? It's not a real problem, in particular if this attribute doesn't apply to internal windows. You can also, for example, have `split-window' ignore the fixed-sizeness of windows. But it's one of the things you have to take care of. >> You have to bind `window-min-height' and `window-min-width' >> around the splitting code. > > Is that a problem? No. Just another thing you have to take care of. The sizes of windows you see in a saved window configuration are not necessarily the sizes resulting exclusively from applications of `split-window'. >> 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. If the size of the target frame (or window) differs from that 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). martin