From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Window configurations Date: Wed, 28 Apr 2010 11:27:31 +0300 Organization: JURTA Message-ID: <87och4m170.fsf@mail.jurta.org> References: <4BB4CF6B.2000007@alice.it> <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> <4BD7DFD3.5030005@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1272443858 30139 80.91.229.12 (28 Apr 2010 08:37:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 28 Apr 2010 08:37:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 28 10:37:36 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 1O72m0-00059y-D2 for ged-emacs-devel@m.gmane.org; Wed, 28 Apr 2010 10:37:36 +0200 Original-Received: from localhost ([127.0.0.1]:39818 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O72lz-0004IN-PJ for ged-emacs-devel@m.gmane.org; Wed, 28 Apr 2010 04:37:35 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O72lt-0004HJ-5z for emacs-devel@gnu.org; Wed, 28 Apr 2010 04:37:29 -0400 Original-Received: from [140.186.70.92] (port=44823 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O72lq-0004EY-Iv for emacs-devel@gnu.org; Wed, 28 Apr 2010 04:37:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O72lo-0008BQ-In for emacs-devel@gnu.org; Wed, 28 Apr 2010 04:37:26 -0400 Original-Received: from smtp-out2.starman.ee ([85.253.0.4]:58419 helo=mx2.starman.ee) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O72ln-0008Al-Ej for emacs-devel@gnu.org; Wed, 28 Apr 2010 04:37:24 -0400 X-Virus-Scanned: by Amavisd-New at mx2.starman.ee Original-Received: from mail.starman.ee (82.131.68.98.cable.starman.ee [82.131.68.98]) by mx2.starman.ee (Postfix) with ESMTP id 544AB3F41E9; Wed, 28 Apr 2010 11:37:18 +0300 (EEST) In-Reply-To: <4BD7DFD3.5030005@gmx.at> (martin rudalics's message of "Wed, 28 Apr 2010 09:12:19 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:124284 Archived-At: > 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. I agree that in a tiling manager internal windows should have coordinates, and an overlapping manager should ignore windows that don't display buffers (if a window manager will support displaying windows without buffers then window definitions should include a new window parameter for them). > Do you mean left would point to the left neighbor and top to the > neighbor above? Yes. > 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 is easy to do. Since split window trees are order-dependent, a list of windows that defines the window configuration in the tiling manager should be order-dependent too. Thus (window 1 (buffer . 1)) (window 2 (buffer . 2) (left-window . 1)) (window 3 (buffer . 3) (top-window . 1)) (window 4 (buffer . 4) (top-window . 2) (left-window . 3)) will create 1+2 and 3+4, and (window 1 (buffer . 1)) (window 3 (buffer . 3) (top-window . 1)) (window 2 (buffer . 2) (left-window . 1)) (window 4 (buffer . 4) (top-window . 2) (left-window . 3)) will create 1+3 and 2+4. >> 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)). This is right that primitives should be able to do this, and user commands should take restrictions from additional parameters. > 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). Ok, I'll wait until you publish a Bzr branch to look at this. -- Juri Linkov http://www.jurta.org/emacs/