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: Window configurations Date: Mon, 26 Apr 2010 18:16:34 +0200 Message-ID: <4BD5BC62.5070306@gmx.at> References: <4BB4CF6B.2000007@alice.it> <4BB9A469.6050608@alice.it> <4BC072C3.2080302@swipnet.se> <4BC0B692.2000702@alice.it> <4BC0BD6D.3060103@swipnet.se> <4BC0F715.2060605@alice.it> <45EB8DD4-B0F8-4FB3-941F-13FADA4DAD66@swipnet.se> <4BC1854B.2060409@alice.it> <4BC1A9D2.8050607@swipnet.se> <4BC206C0.2010202@alice.it> <87fx2pdvfq.fsf@mail.jurta.org> <87y6gg95ad.fsf@mail.jurta.org> <750140A47B7D4FBD93371813D65478F8@us.oracle.com> <87eii63v4j.fsf@mail.jurta.org> <0840B3F4D9E84706874EDD2CA2CC4236@us.oracle.com> <87vdbhgqgd.fsf@mail.jurta.org> <828BB36311A84C43B96D1F2A559DACAE@us.oracle.com> <87d3xo662u.fsf@mail.jurta.org> <69D40D69CC6F4982A8E91D8D8F0F494F@us.oracle.com> <87r5m4hz39.fsf@mail.jurta.org> <4BD40821.70808@gmx.at> <87zl0rtmqy.fsf@mail.jurta.org> 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: dough.gmane.org 1272299397 4194 80.91.229.12 (26 Apr 2010 16:29:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 26 Apr 2010 16:29:57 +0000 (UTC) Cc: 'Emacs' To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 26 18:29:56 2010 connect(): No such file or directory 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.69) (envelope-from ) id 1O6RBy-00022f-0p for ged-emacs-devel@m.gmane.org; Mon, 26 Apr 2010 18:29:54 +0200 Original-Received: from localhost ([127.0.0.1]:35046 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6RBx-0001zY-6T for ged-emacs-devel@m.gmane.org; Mon, 26 Apr 2010 12:29:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6R0g-0002LV-3G for emacs-devel@gnu.org; Mon, 26 Apr 2010 12:18:14 -0400 Original-Received: from [140.186.70.92] (port=34360 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6R0V-0001yt-Ki for emacs-devel@gnu.org; Mon, 26 Apr 2010 12:18:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6QzU-00051a-Iq for emacs-devel@gnu.org; Mon, 26 Apr 2010 12:17:02 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:59469) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1O6QzT-00050m-Q1 for emacs-devel@gnu.org; Mon, 26 Apr 2010 12:17:00 -0400 Original-Received: (qmail invoked by alias); 26 Apr 2010 16:16:49 -0000 Original-Received: from 62-47-57-183.adsl.highway.telekom.at (EHLO [62.47.57.183]) [62.47.57.183] by mail.gmx.net (mp042) with SMTP; 26 Apr 2010 18:16:49 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+ykh0dxF+yvohuvG4Bv5sKLZqfu94TmXC069rNeA cbUVCahFl3oY9u User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <87zl0rtmqy.fsf@mail.jurta.org> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59999999999999998 X-detected-operating-system: by eggs.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:124223 Archived-At: > Do you plan to create a branch for your rewrite of window.c? > It would be very interesting to look at it. I have to catch up with recent developments on the trunk - currently I'm at revision 99248. And I yet have to write Change Logs. > No, I don't use `split-window'. I use exactly the same algorithm as in > `set-window-configuration', and additionally make new windows. > In my tests, this works correctly. That's what I intended to do when I first looked into this. Making new windows essentially has the problem that when, for whatever reason, coordinates are garbled, you end up with a distorted frame and, in the worst case, crash Emacs. Checking window edges is simple with an existing window tree. But if you build the entire tree from scatch, you also have to provide a safe way to GC windows you made just in case they don't fit. With `split-window' you always add one window at a time and you never make a new one unless you're sure it fits. By no means I want to talk you out of this ;-) but `split-window' is a socially well-established function. Saved window configurations will hardly ever get used that much. And we'll already have a hard time to maintain compatibility, for example, when you want to restore a configuration saved by Emacs 27 in an Emacs 29 session (or vice-versa). >> That said, the *entire* coordinate information of a particular window in >> an EWC would consist of (1) whether it is a horizontal or a vertical >> combination and (2) the proportional space - either a float or the >> fraction of "some largest integer" - occupied by the window wrt to its >> parent window. > > Currently `set-window-configuration-from-sexp' works without these > parameters. But maybe they would be useful for user-defined window > configurations. Users "define" window configurations by splitting and deleting windows. They have no idea of the underlying window tree. But if you don't use `split-window' storing the type of window combinations doesn't make sense anyway. It's just that current window configurations have lots of redundancy: For a vertical combination, the widths of all subwindows are the same as that of the parent window, top-lines can be calculated on the fly by adding the top-line of the left sibling to its height, ... Anyway, the greatest problem IMO is to get windows correlate with their buffers. I don't think that restoring ediff configurations will become ever feasible (unless you build this into the ediff code) and I'm also pessimistic about Info buffers - in particular cloned ones. And obviously we'll fail to handle code based on window objects or overlays with a window property. But for merely "normal" buffers the integrity of buffer-local variables affecting size and appearance of windows displaying them must be preserved. For example, when a buffer has `window-size-fixed' non-nil, any frame resizing step in your `set-window-configuration' should keep the size of the window fixed. martin