From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: grischka Newsgroups: gmane.emacs.devel Subject: Re: Window configurations Date: Fri, 14 May 2010 12:42:38 +0200 Message-ID: <4BED291E.6020601@gmx.de> References: 4BE900E7.3090402@gmx.at <4BE96186.7060504@gmx.de> <4BEA74B7.2070609@gmx.at> <4BEA8D2D.4090109@gmx.de> <4BEAA73F.4060608@gmx.at> <4BEAF487.1070605@gmx.de> <4BEBD2E3.8020200@gmx.at> <4BEBE52D.5080102@gmx.de> <4BEC0458.8050600@gmx.at> <4BEC3321.8010208@gmx.de> <4BECF494.8060702@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: dough.gmane.org 1273833786 1440 80.91.229.12 (14 May 2010 10:43:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 14 May 2010 10:43:06 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 14 12:43:04 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 1OCsMC-0001Wn-BW for ged-emacs-devel@m.gmane.org; Fri, 14 May 2010 12:43:04 +0200 Original-Received: from localhost ([127.0.0.1]:57937 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCsMB-0004L3-K7 for ged-emacs-devel@m.gmane.org; Fri, 14 May 2010 06:43:03 -0400 Original-Received: from [140.186.70.92] (port=38017 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCsLy-0004KY-NK for emacs-devel@gnu.org; Fri, 14 May 2010 06:42:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCsLx-0004Vc-GT for emacs-devel@gnu.org; Fri, 14 May 2010 06:42:50 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:58996) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OCsLx-0004VO-3J for emacs-devel@gnu.org; Fri, 14 May 2010 06:42:49 -0400 Original-Received: (qmail invoked by alias); 14 May 2010 10:42:45 -0000 Original-Received: from unknown (EHLO [10.62.10.148]) [82.113.106.188] by mail.gmx.net (mp011) with SMTP; 14 May 2010 12:42:45 +0200 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX1/6MhliCGv6FhLAWaKwTIA4h8ep9n9r31BIiq0Sme wpcr+580dt0NBe User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) In-Reply-To: <4BECF494.8060702@gmx.at> X-Y-GMX-Trusted: 0 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:124763 Archived-At: martin rudalics wrote: > >> And we'd get this structure from `window-tree', I suppose? > > > > But no! You let the user define it. And/or write one as default. > > (And learn to love your users and to hate heuristics!) > > Then you are missing one point: We need a structure that can be defined > (a) via some layout specification package as the one provided by ECB, > and (b) from user interactions in order to fit it into the desktop.el > framework. In the latter case the user won't care about any such > structures, she simply wants her windows back. If is no necessary to save windows. You'd just use the same configuration to show the same buffers, i.e. throw them at "display-buffer" which calls into your window manager which will create windows in the same place as before by definition, because to do this is the whole point of it: To make sure that same (class of) content is presented to the user in the same trusty topological position always. Anyway, it is true that you'll probably want some nifty code to let the user interactively resize the layout configuration (e.g. by dragging borders with the mouse). It should be doable though. > > A buffer-stack per window stands for some such as "virtually overlapped > > windows", with a notion of "behind" if you want to. Of course it is > > possible to swap the two topmost position, if such semantics exist or > > are desirable. > > The question is what the _standard_ semantics are when a window ceases to > be topmost and we have to move it somewhere else on the stack. The standard semantics for "ceasing to be topmost" on a stack are "pushed down" and "popped off". --- grischka > > martin >