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: Tue, 27 Apr 2010 21:03:38 +0300 Organization: JURTA Message-ID: <87vdbc7oxx.fsf@mail.jurta.org> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1272392267 2102 80.91.229.12 (27 Apr 2010 18:17:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 27 Apr 2010 18:17:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 27 20:17:46 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 1O6pLo-0006PW-Ny for ged-emacs-devel@m.gmane.org; Tue, 27 Apr 2010 20:17:41 +0200 Original-Received: from localhost ([127.0.0.1]:49150 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6pLn-0003NE-G2 for ged-emacs-devel@m.gmane.org; Tue, 27 Apr 2010 14:17:39 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6pIW-0000DW-Fj for emacs-devel@gnu.org; Tue, 27 Apr 2010 14:14:16 -0400 Original-Received: from [140.186.70.92] (port=42738 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6pIU-0000CU-Uj for emacs-devel@gnu.org; Tue, 27 Apr 2010 14:14:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6pIS-000314-Ov for emacs-devel@gnu.org; Tue, 27 Apr 2010 14:14:14 -0400 Original-Received: from smtp-out1.starman.ee ([85.253.0.3]:55996 helo=mx1.starman.ee) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6pIS-00030W-7a for emacs-devel@gnu.org; Tue, 27 Apr 2010 14:14:12 -0400 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Original-Received: from mail.starman.ee (82.131.35.76.cable.starman.ee [82.131.35.76]) by mx1.starman.ee (Postfix) with ESMTP id 983673F4156; Tue, 27 Apr 2010 21:14:05 +0300 (EEST) In-Reply-To: <4BD6DE75.4060306@gmx.at> (martin rudalics's message of "Tue, 27 Apr 2010 14:54:13 +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:124253 Archived-At: >> This suggests that for the generality >> window configurations should be defined as a list of windows with their >> parameters, i.e. very much like frames are defined now. Frame parameters >> to define the frame geometry are `left', `top', `height', and `width'. >> Window parameters to define the window geometry are `left-col', `top-line', >> `total-lines', and `total-cols'. Perhaps, in an overlapping window manager >> they should be in pixels. > > 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 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. > Some window managers are tiling window managers, even Windows XP has one > built in. So even if Emacs permits overlapping windows it will probably > still offer tiled frames too. But none of these window managers define tiled windows as a split window tree. So probably an Emacs' overlapping window manager will not be based on window trees. > Hmm ... windmove never helped me that much. I rewrote the core function > for my own purposes because there are windows I never want to select > interactively but the window behind such an unselectable one (or on the > left or right of it) is the window I really want. This looks like a new "intangible" window property discussed in the window-group threads. Have you implemented this in your rewrite of window.c? >> What problems do you see with cloned Info buffers? > > I never looked into this but I'm surprised that Info buffer would work > out of the box. Do help buffers work well too? No, help buffers don't have an addressing scheme like in Info with (info "(file)node"). Recently I proposed to display Help information in the Info reader. This will save and restore buffers with Help information in the desktop file. -- Juri Linkov http://www.jurta.org/emacs/