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: Wed, 28 Apr 2010 09:12:19 +0200 Message-ID: <4BD7DFD3.5030005@gmx.at> References: <4BB4CF6B.2000007@alice.it> <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> <4BD5BC62.5070306@gmx.at> <87d3xlfdd8.fsf@mail.jurta.org> <4BD6DE75.4060306@gmx.at> <87vdbc7oxx.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 1272447734 11750 80.91.229.12 (28 Apr 2010 09:42:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 28 Apr 2010 09:42:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 28 11:42:13 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 1O73mW-0005QE-Ip for ged-emacs-devel@m.gmane.org; Wed, 28 Apr 2010 11:42:12 +0200 Original-Received: from localhost ([127.0.0.1]:54965 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O73mQ-0001pT-Qx for ged-emacs-devel@m.gmane.org; Wed, 28 Apr 2010 05:42:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O73ef-0007cj-2F for emacs-devel@gnu.org; Wed, 28 Apr 2010 05:34:05 -0400 Original-Received: from [140.186.70.92] (port=38377 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O73eU-00075o-JM for emacs-devel@gnu.org; Wed, 28 Apr 2010 05:34:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O71Rk-0001Pb-FX for emacs-devel@gnu.org; Wed, 28 Apr 2010 03:12:48 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:37255) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1O71Rj-0001Oe-H3 for emacs-devel@gnu.org; Wed, 28 Apr 2010 03:12:36 -0400 Original-Received: (qmail invoked by alias); 28 Apr 2010 07:12:29 -0000 Original-Received: from 62-47-56-25.adsl.highway.telekom.at (EHLO [62.47.56.25]) [62.47.56.25] by mail.gmx.net (mp042) with SMTP; 28 Apr 2010 09:12:29 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/0rd8wILv0nbNqt+6Wb0RijPXstqdCWVIicyIiND 1OVRyS1meuvXoG User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <87vdbc7oxx.fsf@mail.jurta.org> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.56000000000000005 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:124290 Archived-At: >> Sounds reasonable. If we apply this idea today, the restore-from-sexp >> step would decide how to rebuild the window tree from these geometry >> parameters - that means how to nest windows into each others. > > For an overlapping window manager there is no need to rebuild the window > tree from geometry parameters. And for the current tiling window manager > you said that window coordinates are redundant. That's what I said earlier. But if we eventually do need them for an overlapping window manager, we could build them into the current tiling manager. Just that (IMO) the tiling manager needs internal windows to work correctly. So the common format would be your four standard parameters left column, top line, height and width for _all_ windows including internal ones. The restore step for the current tiling manager would have to process the internal windows and reconstruct the nesting by comparing their coordinates with those of the leaf windows - just like the current `set-window-configuration' does in if (!NILP (w->parent)) { if (EQ (p->total_cols, XWINDOW (w->parent)->total_cols)) { XWINDOW (w->parent)->vchild = p->window; XWINDOW (w->parent)->hchild = Qnil; } else { XWINDOW (w->parent)->hchild = p->window; XWINDOW (w->parent)->vchild = Qnil; } where it sets the vertical / horizontal child of a parent window according to whether the number of its columns equals that of its child windows (this work by virtue of Emacs's ability to collapse matryoshka windows although it might not harm much if for such windows the split direction would be inverted). The restore step for the overlapping manager would simply ignore internal windows. So we could restore configurations stored by a tiling manager in an overlapping manager. > That's why I proposed > non-redundant and easy-to-define relative parameters. I think it would > be sufficient to have two relative position parameters `left-window' and > `top-window' (that point to the left/top neighbor window) and two relative > size parameters `width' and `height' (fractions relative to the frame size). > I guess it would be possible to rebuild the window tree from this minimal > set of window parameters. Do you mean left would point to the left neighbor and top to the neighbor above? How would you assign them for a four window configuration like this: ----- |1 |2 | |-----| |3 |4 | ----- Currently either 1+2 and 3+4 or 1+3 and 2+4 form internal windows. How would you convey that information with relative parameters? > This looks like a new "intangible" window property discussed in the > window-group threads. Have you implemented this in your rewrite of > window.c? It's virtually impossible to do that in a strict sense (unless you go for a `post-command-hook'). Note that you can always do a thing like (select-window (minibuffer-window)). What I've done is to make `other-window' by default not select certain window types. That default can be overridden by window parameters. And I wrote a `window-in-direction' function which does this for the window in a given direction (I need this because I never use C-x o). martin